Model-Based system management

ABSTRACT

A model of a system is generated and used as a basis for managing the system. As the system is managed, the system model can be updated to reflect changes to the system. Managing of the system can include one or more of provisioning applications in the system, provisioning applications in virtual systems, provisioning test environments, monitoring the configuration of the system, monitoring the system including the health of the system, performing capacity planning for the system, and propagating attributes to different components in the system.

RELATED APPLICATIONS

This application is a continuation-in-part of U.S. patent applicationSer. No. 10/693,838, filed Oct. 24, 2003, entitled “Integrating Design,Deployment, and Management Phases for Systems”, which is herebyincorporated by reference herein. U.S. patent application Ser. No.10/693,838 claims the benefit of U.S. Provisional Application No.60/452,736, filed Mar. 6, 2003, entitled “Architecture for DistributedComputing System and Automated Design, Deployment, and Management ofDistributed Applications”, which is hereby incorporated herein byreference.

This application is related to the following applications, each of whichis hereby incorporated by reference herein:

-   -   U.S. patent application Ser. No. 11/077,265, filed Mar. 10,        2005, entitled “Model-Based System Provisioning”;    -   U.S. patent application Ser. No. ______, Attorney Docket No.        MS1-2356US, filed concurrently herewith, entitled “Model-Based        Virtual System Provisioning”;    -   U.S. patent application Ser. No. ______, Attorney Docket No.        MS1-2357US, filed concurrently herewith, entitled “Model-Based        Provisioning of Test Environments”;    -   U.S. patent application Ser. No. ______, Attorney Docket No.        MS1-2358US, filed concurrently herewith, entitled “Model-Based        Configuration Management”;    -   U.S. patent application Ser. No. 11/107,419, filed Apr. 15,        2005, entitled “Model-Based System Monitoring”;    -   U.S. patent application Ser. No. 11/107,418, filed Apr. 15,        2005, entitled “Model-Based Capacity Planning”; and    -   U.S. patent application Ser. No. ______, Attorney Docket No.        MS1-2361US, filed concurrently herewith, entitled “Model-Based        Propagation of Attributes”.

BACKGROUND

Computers have become increasingly commonplace in our world and offer avariety of different functionality. Some computers are designedprimarily for individual use, while others are designed primarily to beaccessed by multiple users and/or multiple other computers concurrently.These different functionalities are realized by the use of differenthardware components as well as different software applications that areinstalled on the computers.

Although the variety of available computer functionality and softwareapplications is a tremendous benefit to the end users of the computers,such a wide variety can be problematic for the developers of thesoftware applications as well as system administrators that are taskedwith keeping computers running. Such problems can arise, for example,because of differences in configurations or settings that are requiredby different software applications that a user may try to install on thesame computer. Situations can arise where the settings required by onesoftware application cause another software application to malfunction.By way of another example, situations can arise where two softwareapplications have conflicting requirements on how the operating systemon the computer should be configured. Such situations can cause one orboth of the software applications, and possibly additional applications,to operate incorrectly if both are installed concurrently.

Additionally, many computing systems contain a large number of differentcomponents that must work together and function properly for the entirecomputing system to operate properly. If a component fails to functionproperly, one or more other components that rely on the failed componentmay likewise function improperly. A component may fail to functionproperly due to a software failure and/or a hardware failure. Thesecomponent failures result in the improper operation of the associatedcomputing system.

Accordingly, there is a need for an improved way to manage softwareapplications on computers.

SUMMARY

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used as an aid in determining the scope of the claimed subjectmatter.

Model-based system management with several management disciplines guidedby a common model is discussed herein. In accordance with certainaspects, a model of a system is generated and used as a basis formanaging the system. As the system is managed, the system model can beupdated to reflect changes to the system. Management of the system caninclude one or more of provisioning applications in the system,provisioning applications in virtual systems, provisioning testenvironments, monitoring the configuration of the system, monitoring thesystem including the health of the system, performing capacity planningfor the system, and propagating attributes to different components inthe system.

BRIEF DESCRIPTION OF THE DRAWINGS

The same numbers are used throughout the drawings to reference likefeatures.

FIG. 1 illustrates an example system definition model (SDM) that can beused with the model-based system provisioning described herein.

FIG. 2 illustrates an example use of types, configurations, andinstances.

FIG. 3 is a flowchart illustrating an example process for model-basedsystem management.

FIG. 4 is a flowchart illustrating an example process for provisioning asystem.

FIG. 5 illustrates an example application installation specification inadditional detail.

FIG. 6 is a flowchart illustrating an example of the generation of anapplication installation specification for physical deployment inadditional detail.

FIG. 7 is a flowchart illustrating an example process for provisioning avirtual system.

FIG. 8 illustrates an example workload installation specification inadditional detail.

FIG. 9 is a flowchart illustrating an example of the generation of aworkload installation specification for physical deployment inadditional detail.

FIG. 10 is a flowchart illustrating an example process for provisioninga test environment.

FIG. 11 illustrates an example application installation specification inadditional detail.

FIG. 12 is a flowchart illustrating an example of the generation of anapplication installation specification for physical deployment inadditional detail.

FIG. 13 is a flowchart illustrating an example process for managing andmonitoring the configuration of a system.

FIG. 14 is a flowchart illustrating an example process for creating aconfiguration policy associated with the system.

FIG. 15 is a flowchart illustrating an example process for monitoring asystem.

FIG. 16 illustrates an example health model.

FIG. 17 illustrates multiple components that process data in asequential manner.

FIG. 18 is a flowchart illustrating an example process for capacityplanning.

FIG. 19 illustrates example transactions that are performed by a plannedsystem.

FIG. 20 is a flowchart illustrating an example process for propagatingattributes throughout a system model.

FIG. 21 illustrates an example attribute propagation module thatreceives a system model and various attributes, and propagatesattributes throughout the model.

FIG. 22 illustrates an example general computer environment, which canbe used to implement the techniques described herein.

DETAILED DESCRIPTION

As used herein, an application refers to a collection of instructionsthat can be executed by a processor, such as a central processing unit(CPU) of a computing device. An application can be any of a variety ofdifferent types of software or firmware, or portions thereof. Examplesof applications include programs that run on an operating system, theoperating system, operating system components, services, infrastructure,middleware, portions of any of these, and so forth.

A system definition model (SDM) describes a system that can be managed.Management of a system can include, for example, installing software onthe system, monitoring the performance of the system, maintainingconfiguration information about the system, verifying that constraintswithin the system are satisfied, combinations thereof, and so forth. Asystem can be, for example, an application, a single computing device,multiple computing devices networked together (e.g., via a private orpersonal network such as a local area network (LAN) or via a largernetwork such as the Internet), and so forth.

The systems discussed herein can be virtual systems that include one ormore virtual machines. A virtual machine can be thought of as acomputing device implemented in software. A virtual machine emulates acomputing device, including all of the hardware components of acomputing device (except for possibly the processor(s)). A virtualmachine runs on a computing device in its own isolated andself-contained environment, having its own operating system andoptionally other software installed on it. Multiple virtual machines canbe run on the same computing device, each of the multiple virtualmachines having its own isolated environment and its own operatingsystem installed thereon. A virtual system includes one or morecomputing devices that run a virtual machine. A virtual system caninclude one or more computing devices that already run a virtual machineand/or one or more computing devices that are to have a virtual machineprovisioned thereon. A virtual machine can be provisioned on a computingdevice as part of the virtual system provisioning described herein.

In addition to conventional virtual machines, other forms of containersfor workloads are being contemplated or implemented in the industry,such as “sandboxes” that allow a workload to run within an operatingsystem that is shared with other workloads but which nonetheless providethe workloads more isolation than if the workloads were running directlyin the operating system. These different containers can be viewed as“lightweight” virtual machines, in the sense that they provide many ofthe same benefits as traditional virtual machines with less cost oroperational overhead. The techniques described herein can be used forsuch containers as well as traditional virtual systems, and referencesto virtual machines herein include such other forms of containers.

FIG. 1 illustrates an example SDM 100 that can be used with themodel-based virtual system provisioning described herein. SDM 100includes a component corresponding to each of one or more softwareand/or hardware components being managed in a virtual system. Thesesoftware and/or hardware components being managed refer to thosesoftware and/or hardware components that the author of SDM 100 and/ordesigners of the system desires to include in SDM 100. Examples ofhardware and/or software components that could be in a system include anapplication (such as a database application, email application, fileserver application, game, productivity application, operating system,and so forth), particular hardware on a computer (such as a networkcard, a hard disk drive, one of multiple processors, and so forth), avirtual machine, a computer, a group of multiple computers, and so on. Asystem refers to a collection of one or more hardware and/or softwarecomponents.

SDM 100 represents a system including component 102, component 104,component 106, component 108, component 110, component 112, andcomponent 114. Although the example SDM 100 includes seven components,in practice a system, and thus the SDM, can include any number ofcomponents.

For example, component 106 could represent a particular computer, whilecomponent 104 represents an operating system running on that particularcomputer. By way of another example, component 106 could represent anoperating system, while component 104 represents a database applicationrunning on the operating system. By way of yet another example,component 114 could represent a particular computer, while component 112represents an operating system installed on that particular computer,component 110 represents a virtual machine running on the operatingsystem, and component 108 represents an operating system running on thevirtual machine. Note that the operating systems associated withcomponent 112 and component 108 could be the same or alternatively twodifferent operating systems.

The SDM is intended to be a comprehensive knowledge store, containingall information used in managing the system. This information includesinformation regarding the particular components in the system, as wellas relationships among the various components in the system. Despitethis intent, it is to be appreciated that the SDM may contain only someof the information used in managing the system rather than all of theinformation.

Relationships can exist between different components in a system, andthese relationships are typically illustrated in SDM diagrams with linesconnecting the related components. Examples of relationships that canexist between components include containment relationships, hostingrelationships, and communication relationships. Containmentrelationships identify one component as being contained by anothercomponent—data and definitions of the component being contained areincorporated into the containing component. When a component isinstalled on a system, any components contained in that component arealso typically installed on the system. In FIG. 1, containmentrelationships are illustrated by the diagonal lines connecting component102 and component 104, and connecting component 102 and component 108.

Hosting relationships identify dependencies among components. In ahosting relationship, the hosting component typically must be present inorder for the guest component to be included in the system. In FIG. 1,hosting relationships are illustrated by the vertical lines connectingcomponent 104 and component 106, connecting component 108 and component110, connecting component 110 and 112, and connecting component 112 and114.

Communication relationships identify components that can communicatewith one another. Communication relationships may or may not imply thata dependency exists between the components. In FIG. 1, communicationrelationships are illustrated by the horizontal line connectingcomponent 104 and component 108.

Associated with each component in SDM 100 is one or more information(info) pages. Information pages 122 are associated with component 102,information pages 124 are associated with component 104, informationpages 126 are associated with component 106, information pages 128 areassociated with component 108, information pages 130 are associated withcomponent 110, information pages 132 are associated with component 112,and information pages 134 are associated with component 114. Eachinformation page contains information about the associated component.Different types of information can be maintained for differentcomponents. One or more information pages can be associated with eachcomponent in SDM 100, and the particular information that is included ina particular information page can vary in different implementations. Allthe information can be included on a single information page, oralternatively different pieces of information can be grouped together inany desired manner and included on different pages. In certainembodiments, different pages contain different types of information,such as one page containing installation information and another pagecontaining constraint information. Alternatively, different types ofinformation may be included on the same page, such as installationinformation and constraint information being included on the same page.

Examples of types of information pages include installation pages,constraint pages, monitoring pages, service level agreement pages,description pages, and so forth. Installation pages include informationdescribing how to install the associated component onto anothercomponent (e.g., install an application onto a computer), such as whatfiles to copy onto a hard drive, what system settings need to be addedor changed (such as data to include in an operating system registry),what configuration programs to run after files are copied onto the harddrive, sequencing specifications that identify that a particularinstallation or configuration step of one component should be completedbefore an installation or configuration step of another component, andso forth.

Constraint pages include information describing constraints for theassociated component, including constraints to be imposed on theassociated component, as well as constraints to be imposed on the systemin which the associated component is being used (or is to be used).Constraints imposed on the associated component are settings that thecomponent should have (or alternatively should not have) when thecomponent is installed into a system. Constraints imposed on the systemare settings (or other configuration items, such as the existence ofanother application or a piece of hardware) that the system should have(or alternatively should not have) in order for the associated componentto be used in that particular system.

It should also be noted that constraints can flow across relationships.For example, constraints can identify settings that any component thatis contained by the component, or that any component that contains thecomponent, should have (or alternatively should not have). By way ofanother example, constraints can identify settings that any componentthat is hosted by the component, or that any component that hosts thecomponent, should have (or alternatively should not have). By way of yetanother example, constraints can identify settings that any componentthat communicates with the component should have (or alternativelyshould not have).

In addition, constraint pages may also include a description of howparticular settings (or components) are to be discovered. For example,if a constraint indicates that an application should not co-exist withMicrosoft® SQL Server, then the constraint page could also include adescription of how to discover whether Microsoft® SQL Server isinstalled in the system. By way of another example, if a constraintindicates that available physical memory should exceed a certainthreshold, then the constraint page could also include a description ofhow to discover the amount of available physical memory in the system.By way of still another example, if a constraint indicates that asecurity setting for Microsoft® SQL Server should have a particularvalue, then the constraint page could also include a description of howto discover the value of that security setting for Microsoft® SQLServer.

Constraint pages may also include a description of how particularsettings are to be modified if they are discovered to not be incompliance with the constraints. Alternatively, the constraint pagescould include specifications of some other action(s) to take ifparticular settings are discovered to not be in compliance with theconstraints, such as sending an event into the system's event log,alerting an operator, starting a software application to take somecorrective action, and so forth. Alternatively, the constraint pagescould include a policy that describes what action to take under variouscircumstances, such as depending on the time of day, depending on thelocation of the system.

Constraint pages may also optionally include default values for at leastsome of these settings, identifying a default value to use within arange of values that satisfy the constraint. These default values can beused to assist in installation of an application, as discussed in moredetail below.

Monitoring pages include information related to monitoring theperformance and/or health of the associated component. This informationcan include rules describing how the associated component is to bemonitored (e.g., what events or other criteria to look for whenmonitoring the component), as well as what actions to take when aparticular rule is satisfied (e.g., record certain settings or whatevents occurred, sound an alarm, etc.).

Service level agreement pages include information describing agreementsbetween two or more parties regarding the associated component (e.g.,between the purchaser of the associated component and the seller fromwhich the associated component was purchased). These can be accessedduring operation of the system to determine, for example, whether theagreement reached between the two or more parties is being met by theparties.

Description pages include information describing the associatedcomponent, such as various settings for the component, or othercharacteristics of the component. These settings or characteristics caninclude a name or other identifier of the component, the manufacturer ofthe component, when the component was installed or manufactured,performance characteristics of the component, and so forth. For example,a description page associated with a component that represents acomputing device may include information about the amount of memoryinstalled in the computing device, a description page associated with acomponent that represents a processor may include information about thespeed of the processor, a description page associated with a componentthat represents a hard drive may include information about the storagecapacity of the hard drive and the speed of the hard drive, and soforth.

As can be seen in FIG. 1, an SDM maintains various information (e.g.,installation, constraints, monitoring, etc.) regarding each component inthe system. Despite the varied nature of these information pages, theyare maintained together in the SDM and thus can all be readily accessedby various utilities or other applications involved in the management ofthe system.

An SDM can be generated and stored in any of a variety of different waysand using any of a variety of different data structures. For example,the SDM may be stored in a database. By way of another example, the SDMmay be stored in a file or set of multiple files, the files beingencoded in XML (Extensible Markup Language) or alternatively some otherform. By way of yet another example, the SDM may not be explicitlystored, but constructed each time it is needed. The SDM could beconstructed as needed from information existing in other forms, such asinstallation specifications.

In certain embodiments, the SDM is based on a data structure formatincluding types, instances, and optionally configurations. Eachcomponent in the SDM corresponds to or is associated with a type, aninstance, and possibly one or more configurations. Additionally, eachtype, instance, and configuration corresponding to a particularcomponent can have its own information page(s). A type refers to ageneral template having corresponding information pages that describethe component generally. Typically, each different version of acomponent will correspond to its own type (e.g., version 1.0 of asoftware component would correspond to one type, while version 1.1 ofthat software component would correspond to another type). Aconfiguration refers to a more specific template that can include morespecific information for a particular class of the type. An instancerefers to a specific occurrence of a type or configuration, andcorresponds to an actual physical component (software, hardware,firmware, etc.).

For types, configurations, and instances associated with a component,information contained in information pages associated with an instancecan be more specific or restrictive than, but generally cannotcontradict or be broader than, the information contained in informationpages associated with the type or the configuration. Similarly,information contained in information pages associated with aconfiguration can be more specific or restrictive than, but cannotcontradict or be broader than, the information contained in informationpages associated with the type. For example, if a constraint pageassociated with a type defines a range of values for a buffer size, theconstraint page associated with the configuration or the instance coulddefine a smaller range of values within that range of values, but couldnot define a range that exceeds that range of values.

It should be noted, however, that in certain circumstances a model of anexisting system as deployed (that is, a particular instance of a system)may violate the information contained in information pages associatedwith the type for that existing system. This situation can arise, forexample, where the system was deployed prior to an SDM for the systembeing created, or where a user (such as a system administrator) may haveintentionally deployed the system in noncompliance with the informationcontained in information pages associated with the type for thatexisting system.

The use of types, configurations, and instances is illustrated in FIG.2. In FIG. 2, a type 202 corresponds to a particular component. Threedifferent instances 204, 206, and 208 of that particular component existand are based on type 202. Additionally, a configuration (config) 210exists which includes additional information for a particular class ofthe particular component, and two instances 212 and 214 of thatparticular class of the particular component.

For example, assume that a particular component is a databaseapplication. A type 202 corresponding to the database application iscreated, having an associated constraint information page. Theconstraint information page includes various general constraints for thedatabase application. For example, one of the constraints may be a rangeof values that a particular buffer size should be within for thedatabase application. Type 202 corresponds to the database applicationin general.

Each of the instances 204, 206, and 208 corresponds to a differentexample of the database application. Each of the instances 204, 206, and208 is an actual database application, and can have its own associatedinformation pages. For example, each instance could have its ownassociated description information page that could include a uniqueidentifier of the particular associated database application. By way ofanother example, the constraint information page associated with eachinstance could include a smaller range of values for the buffer sizethan is indicated in the constraint information page associated withtype 202.

The information pages corresponding to the instances in FIG. 2 can be inaddition to, or alternatively in place of, the information pagescorresponding to the type. For example, two constraint information pagesmay be associated with each instance 204, 206, and 208, the firstconstraint information page being a copy of the constraint informationpage associated with type 202 and the second constraint information pagebeing the constraint information page associated with the particularinstance and including constraints for just that instance.Alternatively, a single constraint information page may be associatedwith each instance 204, 206, and 208, the single constraint informationpage including the information from the constraint information pageassociated with type 202 as well as information specific to theparticular instance. For example, the range of values that theparticular buffer size should be within for the database applicationwould be copied from the constraint information page associated withtype 202 to the constraint information page associated with eachinstance. However, if the constraint information page for the instanceindicated a different range of values for that particular buffer size,then that different range of values would remain in the constraintinformation page associated with the instance rather than copying therange of values from the constraint information page associated withtype 202.

Following this example of a database application, configuration 210corresponds to a particular class of the database application. Forexample, different classes of the database application may be definedbased on the type of hardware the application is to be installed on,such as different settings based on whether the computer on which thedatabase application is to be installed is publicly accessible (e.g.,accessible via the Internet), or based on whether an operating system isalready installed on the server. These different settings are includedin the constraint information page associated with configuration 210.

Each of the instances 212 and 214 corresponds to a different example ofthe database application. Similar to instances 204, 206, and 208, eachof instances 212 and 214 is an actual database application, and can haveits own information page(s). However, unlike instances 204, 206, and208, the constraint information pages associated with instances 212 and214 each include the constraints that are in the constraint informationpage associated with configuration 210 as well as the constraints in theconstraint information page associated with type 202.

It should be noted that, although the information pages are discussed asbeing separate from the components in the SDM, the data structure(s)implementing the SDM could alternatively include the informationdiscussed as being included in the various information pages. Thus, thecomponent data structures themselves could include the informationdiscussed as being included in the various information pages rather thanhaving separate information pages.

The installation page associated with a component can be used as a basisfor provisioning a system. Provisioning a system refers to installing anapplication(s) on the system, as well as making any necessary changes tothe system in order for the application(s) to be installed. Suchnecessary changes can include, for example, installing an operatingsystem, installing one or more other applications, setting configurationvalues for the application or operating system, and so forth.

The installation page associated with a component can also be used as abasis for provisioning a virtual system. Provisioning a virtual systemrefers to installing a workload on the virtual system, as well as makingany necessary changes to the virtual system in order for the workload tobe installed. Such necessary changes typically include creating a newvirtual machine, and can also include other actions, such as installingan operating system on the computing device on which the new virtualmachine runs or installing an operating system on the newly createdvirtual machine, setting configuration values for the operating system,installing one or more other applications, and so forth. In certainimplementations, the workload is installed by creating a new virtualmachine on a computing device and copying an image file to the storagedevice of the computing device. This image file includes anapplication(s) to be run to perform the computing of the workload, andalso typically includes the operating system on which the application(s)is to be run.

In the discussions herein, reference is made to different classes ofcomputing devices. Each of these different classes of computing devicesrefers to computing devices having particular common characteristics, sothey are grouped together and viewed as a class of devices. Examples ofdifferent classes of devices include IIS (Internet Information Services)servers that are accessible to the Internet, IIS servers that areaccessible only on an internal intranet, database servers, emailservers, order processing servers, desktop computers, and so forth.Typically, each different class of computing device corresponds to oneof the configurations in the system model.

These different classes of computing devices can be different classes ofphysical devices, as well as different classes of virtual machines. Theclasses may distinguish between virtual machine classes and physicaldevice classes. For example, one class may be database virtual machines,another class may be database physical servers (not running the databaseon a virtual machine), another class may be an order processing virtualmachine, another class may be an order processing physical server (notrunning the order processing application(s) on a virtual machine), andso forth. Alternatively, the classes may not distinguish between virtualmachine classes and physical device classes. For example, a singledatabase server class may be used for database servers regardless ofwhether the database application(s) are run on a virtual machine or acomputing device without a virtual machine(s).

FIG. 3 is a flowchart illustrating an example process 300 formodel-based system management. Portions of process 300 can beimplemented in software, firmware, and/or hardware.

Initially, an application model(s) and/or a system model is accessed(act 302). One or both of these models may be created by the same useras is initiating access to the model(s), or alternatively one or more ofthese models may be created by another user. Each accessed model is anSDM model analogous to model 100 of FIG. 1, and includes one or morecomponents. Each accessed model includes types and instances, andoptionally configurations and relationships. As the system is managed,these models can be updated to reflect any changes to the system.Typically, a different application model can be accessed for eachapplication in a system (or to be added to a system). However, once theapplication is installed in the system, the application model becomespart of the system model.

One or more actions can then be taken to manage the system based on oneor both of the application model(s) and the system model. These samemodels are the basis for all of the actions, and these models can becontinuously updated and changed by these actions. These variousmanagement actions refer to actions for different managementdisciplines, such as provisioning systems, health monitoring, predictingsystem capacity, and so forth. Each of these management actions can beperformed with the aid of a model(s), but the value is greater when aplurality of management actions are based on the same set of models. Forexample, the cost of creating the models is depreciated over severaltasks rather than each task having to bear the complete cost of themodel generation. By way of another example, management cost is reducedand management effectiveness is increased by the consistency that comesfrom using the same model (e.g., because a health and performancemonitoring system will base its decisions on the same model that theprovisioning system deployed).

One action that can be taken is to provision systems based on one orboth of the application model(s) and the system model (act 304).Examples of such provisioning of systems are discussed in more detailbelow in the System Provisioning section.

Another action that can be taken is to provision virtual systems basedon one or both of the application model and the system model (act 306).Examples of such provisioning of virtual systems are discussed in moredetail below in the Virtual System Provisioning section.

Another action that can be taken is to provision test environments basedon one or both of the application model and the system model (act 308).Examples of such provisioning of test environments are discussed in moredetail below in the Test Environment Provisioning section.

Another action that can be taken is to update one or both of theapplication model and the system model based on deployments that aremade (act 310). When an application is installed it the system, thesystem model is updated to incorporate the application model. Examplesof such updating are discussed in more detail below in the SystemProvisioning, Virtual System Provisioning, and Test EnvironmentProvisioning sections.

Another action that can be taken is to predict system capacity based onone or both of the application model and the system model (act 312).Examples of such predicting are discussed in more detail below in theCapacity Planning section.

Another action that can be taken is to monitor the health of the systembased on one or both of the application model and the system model (act314). Examples of such monitoring are discussed in more detail below inthe System Monitoring section.

Another action that can be taken is to manage configurations of thesystem based on one or both of the application model and the systemmodel (act 316). Examples of such configuration management are discussedin more detail below in the Configuration Monitoring section.

Another action that can be taken is to update one or both of theapplication model and the system model by propagating attributes (act318). Examples of such attribute propagation are discussed in moredetail below in the Attribute Propagation section.

System Provisioning

FIG. 4 is a flowchart illustrating an example process 400 forprovisioning a system. Portions of process 400 can be implemented insoftware, firmware, and/or hardware.

Initially, a model of the application to be installed on a system isbuilt (act 402). This building process in act 402 is typically performedby the developer of the application, although could alternatively beperformed by others. This model is an SDM model of the application,analogous to model 100 of FIG. 1, and includes one or more components.The model of the application includes types and optionallyconfigurations. As part of the building process in act 402, zero or moreinformation pages are associated with each component in the model.Typically, at least a constraint information page is associated witheach component in the model.

As part of the building process in act 402, types and optionallyconfigurations are defined, along with associated information page(s).The types and configurations can be standard types or configurationsthat are copied or modified in act 402, or alternatively can be newlycreated in act 402. As discussed above, different constraints can beincluded in the configuration information page associated with the typeand the configuration information page associated with theconfiguration.

The constraints included on a constraint information page can take avariety of forms, such as: hardware requirements regarding the computingdevice(s) or other hardware on which the application is to be installed(e.g., a minimum processor speed, a minimum amount of memory, a minimumamount of free hard drive space, a minimum amount of network bandwidthavailable, particular security mechanisms available, and so forth),software requirements regarding the computing device(s) or otherhardware or software on which the application is to be installed (e.g.,a particular operating system that should already be installed on thecomputing device(s), one or more other applications that should alreadybe installed on the computing device(s), specifications regarding howparticular hardware and/or the operating system is to be configured suchas particular settings for the operating system that should already bemade, a particular type of security or encryption that should be in use,and so forth), other requirements regarding the computing device(s) onwhich the application is to be installed (e.g., particular security keysavailable, data center policies that should be enforced, authenticationthat is used, system topology, etc.), and so on.

Constraints can be positive requirements specifying that somethingshould be present (e.g., the processor should have at least a minimumprocessor speed, or the Windows® XP operating system should already beinstalled on the computing device). Constraints can also be negativerequirements specifying that something should not be present (e.g., oneor more particular applications should not already be installed on thecomputing device, or particular operating system settings should not bepresent).

Additionally, a model of the system where the application is to beinstalled is built (act 404). This building process in act 404 istypically performed by an administrator of the system where theapplication is to be installed, although could alternatively beperformed by others. This model is an SDM model of the system analogousto model 100 of FIG. 1, and includes one or more components. The modelof the system includes types and instances, and optionallyconfigurations. The system in act 404 could be a single computingdevice, or alternatively multiple computing devices. For example, if theapplication will be installed on one computing device in a data centerhaving a thousand computing devices, then the model of the system wherethe application is to be installed may include all or some of thosethousand computing devices. By way of another example, if theapplication will be installed on a home computer that is not coupled toany other computers, then the model of the system where the applicationis to be installed will include just that home computer.

Oftentimes, the model of the system built in act 404 will be generatedby the system administrator prior to the application being designed andthe model of the application being built in act 402. In such situations,the previously generated model can be accessed and need not be re-builtin act 404.

Components in the model of the system built in act 404 will includeconstraint information pages. These constraint information pages includeconstraints for each component in the system. Such constraintinformation pages can identify constraints for the correspondingcomponent, and optionally constraints that should be satisfied by anyapplication to be installed on the corresponding component.

Based on the models built in acts 402 and 404, a logical deploymentevaluation is performed (act 406). The logical deployment evaluationinvolves comparing the model of the application (from act 402) to themodel of the system (from act 404) to determine whether the applicationcould be installed in the system. Typically, the application designer orsystem administrator will identify a particular class (or classes) ofcomputing device on which he or she desires to install the application.Alternatively, the application may be compared to all classes ofcomputing devices in the system.

The constraints and/or description information for the application arecompared to the constraints for that class of computing device todetermine whether the application satisfies the constraints of the classof computing device, and the constraints and/or description informationfor the class of computing device are compared to the constraints forthe application to determine whether the class of computing devicesatisfies the constraints of the application. The constraints anddescription information for all components of the class of computingdevice, including applications that are hosted by the class of computingdevice (e.g., an operating system as well as possibly otherapplications) are also accessed as part of the logical deploymentevaluation. These constraints used in the logical deployment evaluationcan include constraints that are flowed across relationships, asdiscussed above. Accessing the constraints for the operating system andother applications allows verification that, if installed on a device ofthe class of computing device, settings made on the computing device forthe application would not conflict with current settings for otherapplications installed on the computing device.

By way of example, a particular constraint on the application mayindicate that the computing device should have a minimum processorspeed. A description page associated with the class of computing device(or the processor of the class of computing device) would be accessed toverify that the speed of the processor is at least the minimum processorspeed. By way of another example, a particular constraint on the classof computing device may indicate that a software firewall should alwaysbe running on the class of computing device. A description pageassociated with the application would be accessed to verify that theapplication does not require a software firewall to be deactivated. Byway of yet another example, another application already installed on theclass of computing device may indicate that memory in the computingdevice should be configured or accessed in a particular manner. Adescription page associated with the application would be accessed toverify that the application does not require configuration or access tothe memory that is inconsistent with that particular manner.

The results of the evaluation in act 406 can be returned to theapplication designer and/or system administrator. An indication ofsuccess (if all of the constraints are satisfied) or failure (if all ofthe constraints are not satisfied) can be returned. In addition, if oneor more of the constraints are not satisfied, then an indication ofwhich constraint was not satisfied can be returned, as well asoptionally an indication of which component caused the constraint to notbe satisfied. Returning such information can assist the applicationdeveloper in modifying the application so that it can be installed inthe system.

Process 400 then proceeds based on the results of the evaluation in act406. If the evaluation indicates that the application can be installedin the system, then process 400 can proceed to act 408. However, if theevaluation indicates that the application cannot be installed in thesystem, then the evaluation of act 406 can be repeated for a differentclass of computing device in the system, or alternatively theapplication may be modified in order to overcome the problem(s)identified in the evaluation of act 406, and process 400 can return toact 402 to build a model of the modified application.

In act 408, physical deployment of the application is determined.Determining physical deployment of the application refers to identifyingwhich particular computing device(s) the application will be installedon. As part of act 408, a determination is made as to whetherinstallation of the application on a particular computing device ispermissible in light of constraints on the number of instances of theapplication that are to be installed. In act 406 it was verified that itwas permissible to install the application on a particular type orconfiguration (e.g., a particular class of computing device), but theremay still be constraints on how many instances of the application can beinstalled on particular computing devices (e.g., particular instances ofthat class of computing device). A particular computing device may haveconstraints allowing any number of instances of an application to beinstalled, constraints indicating at least a minimum number of instancesof an application should be installed, and/or constraints indicatingthat no more than a maximum number of instances of an application shouldbe installed. As part of act 408, verification that the number ofinstances of the application to be installed on the computing device donot violate the constraints regarding the number of instances of theapplication that can be installed on the computing device is performed.

A particular one or more of the computing devices on which theapplication could be installed is identified in act 408. The particularcomputing device(s) on which the application is to be installed can beidentified in different manners. One way in which the particularcomputing device(s) on which the application is to be installed can beidentified is manually, such as by a system administrator or other partymanually selecting a particular computing device(s). This manuallyselected computing device(s) could be a computing device(s) already inthe system, or alternatively a new computing device(s) that needs to bepurchased or a computing device(s) that needs to be removed from storageand added to the system (e.g., coupled to the network that the othercomputing devices in the system are coupled to).

Alternatively, the particular computing device(s) on which theapplication is to be installed can be identified automatically. Anapplication running in the system can identify various characteristicsof the computing devices on which the application could possibly beinstalled (e.g., the computing devices of the particular class ofcomputing device on which the application is to be installed), such asload characteristics of each computing device. The load characteristicscould identify, for example, the average or maximum amount of processorusage, the average amount of memory usage, the amount of availablenetwork bandwidth being used, the amount of hard disk drive space beingused, and so forth. Based on these load characteristics, the computingdevice(s) most likely to be able to support the application would beidentified as the computing device(s) on which the application is to beinstalled (e.g., the application having the lightest load, such as thelowest average processor usage, the smallest amount of available networkbandwidth being used, the most hard disk drive space available, and soforth).

Alternatively, the particular computing device(s) on which theapplication is to be installed can be identified in a semi-automaticmanner. An application running in the system can identify variouscharacteristics of the computing devices on which the computer couldpossibly be installed analogous to the automatic manner, and thenpresent those results to a user (such as the system administrator) formanual selection of one or more of the computing devices. One or more ofthe computing devices may optionally be recommended to the user as thebest candidate(s) for selection, but the ultimate selection would remainat the user's discretion.

An application installation specification for physical deployment of theapplication is then generated (act 410). The application installationspecification can be saved as an installation page associated with thecomponent representing the application in the application model. Theapplication installation specification includes an identification, foreach class of device in the system on which the application may beinstalled, of how to install the application. As each of theseidentifications indicates how to install the application on a particularclass of devices, these identifications can also be referred to asdevice class installation specifications. The device class installationspecifications can also identify which particular computing device(s) ofthat class the application is to be installed on (the computingdevice(s) determined in act 408). This identification of how to installthe application includes, for example, all of the settings of thecomputing device that should be made or changed, an identification ofall of the files that need to be copied to the computing device andwhere those files should be copied, an order in which files should becopied and/or settings made or changed, any initialization programs thatneed to be run after the files have been copied and/or settings made orchanged, and so forth. This identification may also include installingan operating system and/or one or more additional applications. Forexample, one class of computing device may be a bare computing devicewith no operating system installed on it. In such situations, theinstallation specification for that class of computing device wouldinclude initially installing the appropriate operating system on thecomputing device.

At least a portion of each device class installation specification canbe generated automatically based on the information contained in theinformation pages associated with the software application to beinstalled. As discussed above, the constraint information page caninclude various default values. These default values can be used duringact 410 to identify the settings or configuration values that should beset when installing the application, and thus which should be includedin the device class installation specification. For example, aparticular default value may be included in the configurationinformation page for a buffer size. This default value would be includedin the device class installation specification so that when theapplication is installed on a particular computing device, the computingdevice settings (such as in an operating system registry) can bemodified to include this default value for the buffer size (possiblyreplacing another value for the buffer size previously stored in thecomputing device settings).

In addition to default values, other constraint information included inthe constraint information page can be used in act 410 to identify thesettings or configuration values that should be set when installing theapplication. If a range of values for a particular setting were includedin the constraint information page, then a setting to be used wheninstalling the application can be derived from that range. For example,the lowest value in the range could be selected, the highest value inthe range could be selected, the average of the highest and lowestvalues in the range could be computed and selected, a value in the rangecould be selected randomly, and so forth.

Furthermore, in addition to information contained in the informationpages associated with the application, information contained in theinformation pages associated with the system (such as the computingdevice on which the application is to be installed) can be used as abasis for automatically generating at least a portion of each deviceclass installation specification. Default values and/or ranges of valuescan be used to automatically generate values for the device classinstallation specification in the same manner as discussed above.

It should also be noted that different components can have differentconstraints and different default values for the same settings orconfiguration values. In such situations, even though there is overlapof the constraints so that the different components can all be installedon a system, one or more of the default values may violate theconstraints of another component. Thus, a suitable value that iscompliant with the constraints of all of the components is determined.This suitable value can be determined in different manners, includingmanually, automatically, and semi-automatically. A suitable value can bedetermined manually by a user (such as the system administrator)inputting a suitable value for the setting or configuration value.

A suitable value can be determined automatically by evaluating thevarious constraints and selecting a value that satisfies all theconstraints. This selected value is then used as the suitable value. Forexample, if each constraint lists a range of acceptable values, then avalue that falls within each range of acceptable values can beautomatically identified and used as the suitable value.

A suitable value can be determined semi-automatically by evaluating thevarious constraints and selecting a value that satisfies all theconstraints analogous to the automatic manner. However, rather thanautomatically using the selected value as the suitable value, theselected value can be presented to a user (such as the systemadministrator) for approval. The user can accept this selected value, oralternatively input a different value. Alternatively, rather thanpresenting a single selected value to the user, the range of possiblevalues (or portion of the range of possible values) that satisfies theconstraints of the different components may be presented to the user.

It should further be noted that at least a portion of a device classinstallation specification may be generated manually rather thanautomatically. This manual generation refers to user inputs (such as bythe application developer or system administrator) rather than automaticgeneration by some component or module (e.g., development module 500discussed below). For example, the particular files to be identified inthe device class installation specification may be identified manuallyrather than automatically.

Additionally, an assignment record is generated in act 410 thatmaintains a record of which device class installation specifications areto be used for which device classes. This record can be, for example, amapping of device class to device class installation specification.Thus, given the application installation specification includingmultiple device class installation specifications, a determination as towhich particular device class installation specification to use can bemade based on the class of the device on which the application is to beinstalled. The assignment record generated can also be stored as part ofthe application installation specification.

Alternatively, rather than having a separate assignment record, anidentification of which device class installation specification isassociated with which particular class of device may be maintained inother manners. For example, the indication may be inherent in the namingconvention used for the device class installation specification (e.g.,each device class installation specification may be a separate filehaving a file name that identifies the particular class of device), oreach device class installation specification may include an indicationof the associated class of device.

The application installation specification is generated after thelogical deployment evaluation in act 406. Thus, the applicationinstallation specification is generated only after it is verified thatthe application can be installed in the system. Additionally, theconstraint information (such as default values) associated with theapplication can be used to determine settings to be included in theapplication installation specification. Thus, it can be seen that theapplication installation specification generated in act 410 is derivedat least in part from the model of the application as well as the modelof the system.

After the application installation specification is created, physicaldeployment of the application is performed (act 412). This physicaldeployment includes making the application installation specificationavailable to a deployment system and having the deployment systeminstall the application on the particular device identified in act 408.Once it is given the application installation specification, thedeployment system operates in a conventional manner to install theapplication. Any of a variety of deployment systems could be used in act412, such as the Windows® Installer service or Microsoft® SystemsManagement Server, both available from Microsoft Corporation of Redmond,Wash.

Once the application is installed in the system, the application becomespart of the system and thus the application model is incorporated intothe system model. Thus, after installation of the application, the SDMfor the system includes the SDM of the application.

Alternatively, the evaluation in act 406 may be for a particularcomputing device rather than for a class of computing device. In thisalternative, the evaluation in act 406 is the same as discussed above,except that constraint and description information for a particularinstance of a computing device are used rather than constraint anddescription information for a class of computing device. In suchsituations, the identification of the particular computing device ismade in, or prior to, act 406 rather than in act 408, and can be made inthe same manner as discussed in act 408.

It should also be noted that a particular device class installationspecification may indicate to install the application on multipledifferent computing devices within the system. For example, theapplication developer or system administrator may desire to install theapplication on all of the computing devices of a particular class. Insuch a situation, an indication is included in the device classinstallation specification for that particular device class that theapplication is to be installed on all of the computing devices of thatparticular class, or alternatively may identify the particular computingdevices (e.g., by name or other unique identifier) on which theapplication is to be installed. The deployment system used to installthe application receives this indication and installs the application onthe appropriate computing devices.

FIG. 5 illustrates an example application installation specification inadditional detail. An installation specification development module 500generates an application installation specification 502. Installationspecification module 500 can be implemented in software, firmware,hardware, or combinations thereof, and can perform act 410 of FIG. 4,and optionally additional acts of FIG. 4 (such as act 406 and/or act408). Application installation specification 502 includes multiple (x)device class installation specifications 504(1), 504(2), . . . 504(x).Each of the device class installation specifications 504 identifies howthe application is to be installed on a particular class of computingdevice. Application installation specification 502 also includesspecification assignment record 506 to identify which specification 504corresponds to which class of computing device.

Application installation specification 502 is input to a deploymentsystem 508 along with any necessary installation file(s) 510.Installation file(s) 510 include the file(s) that are to be installed onthe computing device in order to install the application, such as one ormore files of executable code, one or more files of data, and so forth.Alternatively, although illustrated separately, application installationspecification 502 and installation file(s) 510 may be stored together ina single package (e.g., a compressed file).

FIG. 6 is a flowchart illustrating the generation of an applicationinstallation specification for physical deployment of act 410 of FIG. 4in additional detail. FIG. 6 can be implemented in software, firmware,and/or hardware.

Initially, a device class on which the application could be installed isselected (act 602). In certain embodiments the system administratorand/or application developer (or alternatively some other party) maydesire that the application be installed only on certain classes ofdevices, in which case the devices on which the application could beinstalled is less than all of the devices in the system. Alternatively,the application may be able to be installed on any device in the system.

A device class installation specification for the selected device classis then generated, identifying how to install the application on theselected device class (act 604). As discussed above, this generation caninclude using default values included in an information page associatedwith the application in the application model for setting values toinclude in the installation specification being generated.

In some situations, the device class installation specification isgenerated in a format that is expected and understood by a deploymentsystem that will be installing the application. The device classinstallation specification may be generated in this format in act 604,or alternatively may be subsequently translated into this format (e.g.,by a translation component of the distribution system).

It should be noted that different device installation specifications maybe generated for computing devices that will have the same functionalitybut are currently configured differently, such as computing devices thatdo not yet have an operating system installed and computing devices thatalready have an operating system installed. Alternatively, suchcomputing devices may be considered to be part of the same device class,but the device class installation specification would include aconditional portion to be used based on the configuration of theparticular instance of the computing device on which the application isbeing installed (e.g., the conditional portion may be bypassed if thecomputing device already has an installed operating system, or used toinstall an operating system on the computing device if an operatingsystem is not already installed on the computing device).

A check is then made as to whether there are any additional deviceclass(es) in the system for which no device class installationspecification has been generated (act 606). If there are any suchadditional device class(es), then one such additional device class isselected (act 608) and the process returns to act 604 to generate adevice class installation specification for the selected device class.

Returning to act 606, if device class installation specifications havebeen generated for all of the device class(es), then a specificationassignment record is generated associating particular installationspecifications with particular device classes (act 610). Alternatively,the specification assignment record may be generated in act 604 as thedevice class installation specifications are being generated, and anindication of which device class is associated with which device classinstallation specification added to the specification assignment recordas the device class installation specification is generated.

The device class installation specifications generated in act 604 andthe assignment record generated in act 610 are then combined into anapplication installation specification for the application (act 612).

Virtual System Provisioning

Provisioning of virtual systems is based in part on workloads.Generally, a workload is some computing that is to be performed. Aworkload typically includes an application to be executed to perform thecomputing, and can also include the operating system on which theapplication is to be installed. Various configuration informationdescribing how the application and/or operating system is to beconfigured, as well as data to be used by the application and/oroperating system when executing, can also be included in the workload. Amodel of the workload includes the application, operating system,configuration information, and/or data, as well as constraints of theworkload such as resources and/or other capabilities that the virtualmachine(s) on which the workload is to be installed must have. Examplesof these constraints are discussed below.

FIG. 7 is a flowchart illustrating an example process 700 forprovisioning a virtual system. Portions of process 700 can beimplemented in software, firmware, and/or hardware.

Initially, a model of a workload is built (act 702). As discussed above,the workload typically includes the application to be installed on avirtual system, and can also include the operating system, configurationinformation, and/or data. Alternatively, the workload may not include anapplication, but may include an operating system (or components of anoperating system), configuration information, and/or data. The model ofthe workload can also include one or more constraints.

This building process in act 702 is typically performed by the developerof the workload, although could alternatively be performed by others.This model is an SDM model of the workload, analogous to model 100 ofFIG. 1, and includes one or more components. The model of the workloadincludes types and optionally configurations. As part of the buildingprocess in act 702, zero or more information pages are associated witheach component in the model. Typically, at least a constraintinformation page is associated with each component in the model.

As part of the building process in act 702, types and optionallyconfigurations are defined, along with associated information page(s).The types and configurations can be standard types or configurationsthat are copied or modified in act 702, or alternatively can be newlycreated in act 702. As discussed above, different constraints can beincluded in the configuration information page associated with the typeand the configuration information page associated with theconfiguration. The specific constraints included in the configurationinformation page for a particular workload can vary based on theparticular computing to be performed and/or the desires of the designerof the workload.

The constraints included on a constraint information page can take avariety of forms, such as: hardware requirements regarding the computingdevice(s) or other hardware on which the application is to be installed(e.g., a minimum processor speed, a minimum amount of memory, a minimumamount of free hard drive space, a minimum amount of network bandwidthavailable, particular security mechanisms available, and so forth),software requirements regarding the computing device(s) or otherhardware or software on which the workload is to be installed (e.g., aparticular operating system that should already be installed on thecomputing device(s), one or more other applications that should alreadybe installed on the computing device(s), specifications regarding howparticular hardware and/or the operating system is to be configured suchas particular settings for the operating system that should already bemade, a particular type of security or encryption that should be in use,and so forth), requirements regarding a virtual machine that should becreated on a computing device as well as requirements regarding anoperating system that should be installed on the virtual machine beforethe application can be installed thereon, other requirements regardingthe computing device(s) on which the workload is to be installed (e.g.,particular security keys available, data center policies that should beenforced, authentication that is used, system topology, etc.), and soon.

Constraints can be positive requirements specifying that somethingshould be present (e.g., the processor should have at least a minimumprocessor speed, or the Windows® XP operating system should already beinstalled on the computing device). Constraints can also be negativerequirements specifying that something should not be present (e.g., oneor more particular applications should not already be installed on thecomputing device, or particular operating system settings should not bepresent).

One example constraint of the workload is a number and/or size of CPUsthat the system on which the workload is to be installed must have. Thisconstraint can identify a specific number of CPUs that the system musthave (e.g., 1 CPU, 2 CPUs, 4 CPUs, etc.), or a range of CPUs that thesystem must have (e.g., 2 to 4 CPUs). The constraint can also specifythe size of the CPUs that are needed, referring to the fraction of a CPUthat is needed (e.g., a workload may require 100% of 1 CPU, or 50% ofeach of 2 CPUs). Both requirements and recommendations can be specified(e.g., a minimum of 2 CPUs is required, but 4 or more CPUs should beused if possible).

Another example constraint of the workload is an amount of memory (e.g.,RAM). This constraint typically identifies a minimum amount of memorythat the system on which the workload is to be installed must have. Bothrequirements and recommendations can be specified (e.g., a minimum of 2GB of memory is required, but 4 GB or more of memory should be used ifpossible).

Another example constraint of the workload is an amount of storage space(e.g., hard disk space, optical disk space, etc.). This constrainttypically identifies a minimum amount of storage space that the systemon which the workload is to be installed must have. Both requirementsand recommendations can be specified (e.g., a minimum of 10 GB ofstorage space is required, but 15 GB or more of storage space should beused if possible).

Another example constraint of the workload is the hardware type orarchitecture. For example, particular types of CPUs, particular bus ormemory speeds, particular co-processors, and so forth may be requiredand/or recommended.

Another example constraint of the workload is the type of storageavailable to the system. This constraint can specify performance andreliability characteristics of the storage (e.g., RAID 1 or RAID 5 isrequired). This constraint can also specify that access to particularsystems or databases is required. Both requirements and recommendationscan be specified (e.g., RAID 1 or RAID 5 is required, but RAID 5 shouldbe used if possible).

Another example constraint of the workload is the schedule for theworkload, referring to when the computing that is to be performed shouldbe started and/or ended. Both requirements and recommendations can bespecified (e.g., the computing must end by 6:00 am, but should end by5:00 am if possible).

Another example constraint is the events that should trigger thedeployment of the workload, referring to when the computing that is tobe performed should be started and/or ended. For example, when the sameworkload is operating on several computing devices with tasks assignedto the individual devices and/or virtual machines by a load balancingdevice, a monitoring system may determine that the number of incomingrequests is exceeding the aggregate capacity of the devices and/orvirtual machines, and may send an event indicating that another instanceof that workload should be deployed to help carry the load. By way ofanother example, when a running workload fails because of a software orhardware problem, a monitoring system may send an event that indicatesthat a replacement copy of that workload should be deployed.

The constraints may also include a combination of events and schedules.For example, a workload may be started by a schedule, and theconstraints specify that the workload should be ended and removed fromthe computing device when processing is finished, as indicated by anevent; however, if the processing is not completed when the “batchwindow closes” at 6:00 am, the workload should be paused and removedfrom the computing device, and restarted to continue processing when thenext “batch window” opens at the following midnight.

These constraints of the workload can refer to constraints on thephysical hardware of the virtual system and/or constraints on thevirtual hardware of a virtual machine of the virtual system. The modelof the workload identifies whether the constraints refer to physicalhardware or virtual hardware. Typically, the constraints of the workloadidentify constraints of the virtual hardware, and these constraints canbe compared to the constraints of the system to verify that a virtualmachine having virtual hardware satisfying these constraints of theworkload can be created. Alternatively, the constraints of the workloadcan be compared to the constraints of currently running virtual machinesto verify that a virtual machine having virtual hardware satisfyingthese constraints of the workload exists. In another alternative, theconstraints of the workload identify constraints of the physicalhardware, and these constraints can be compared to the constraints ofthe system to verify that a computing device satisfying theseconstraints exists.

Additionally, the workload may have different constraints that apply fordifferent types of deployment. For example, if the workload is deployedand started from a state where it is not previously running, a certainset of constraints apply, but if the workload is started after havingbeen previously executing, paused and saved in a virtual machine imagefile, another set of constraints apply, and if the workload is to bemoved from one computing device to another through a migration process,yet another set of constraints apply.

Additionally, a model of the system where the application is to beinstalled is built (act 704). This building process in act 704 istypically performed by an administrator of the system where theapplication is to be installed, although could alternatively beperformed by others. This model is an SDM model of the system analogousto model 100 of FIG. 1, and includes one or more components. The modelof the virtual system includes types and instances, and optionallyconfigurations.

The system in act 704 can be referred to as a virtual system, althoughthe virtual machine(s) onto which the application and the operatingsystem of the workload are to be installed may not yet be created. Assuch, the system in act 704 describes the physical computing devices onwhich virtual machines may be created, and describes virtual machinesthat have already been created, but does not describe virtual machinesthat have not yet been created.

The system in act 704 could be a single computing device, oralternatively multiple computing devices. For example, if theapplication will be installed on a virtual machine of a computing devicein a data center having a thousand computing devices, then the model ofthe system where the application is to be installed will include thosethousand computing devices. By way of another example, if theapplication will be installed on a virtual machine of a home computerthat is not coupled to any other computers, then the model of the systemwhere the application is to be installed will include just that homecomputer.

It should also be noted that the exact nature of a computing device canvary, and that any of a wide variety of computing devices can be asystem in act 704. For example, “hierarchical” computers can exist, suchas a rack that can contain multiple chassis, each chassis can containmultiple blades, each blade can contain multiple motherboards, eachmotherboard can contain multiple processors, and each processor cancontain multiple cores. Any of these components of such a hierarchicalcomputer can be viewed as a computing device (e.g., the rack can be acomputing device, each chassis can be a computing device, each blade canbe a computing device, each motherboard can be a computing device, eachprocessor can be a computing device, and/or each core can be a computingdevice).

The characteristics of each computing device in the hierarchy, and thecharacteristics of the containment, hosting and communicationsrelationships among them, are typically significant for the placement ofvirtual machines on those computing devices. For example, the speed ofthe connection may determine how a workload can be deployed, andtherefore a constraint in the workload model indicates that the workloadcannot be deployed across several computing devices at a level in thehierarchy where the connection speed is too slow. By way of anotherexample, while it may be possible to deploy a workload down to the levelof a single core, it may not be desirable to do so because ofunpredictable performance interactions between workloads on the coreswithin one processor, and in this case the workload model hasconstraints that the workload should not be deployed on a computingdevice below the level of a processor in the hierarchy, or below a levelwhere certain performance guarantees can be met, which would bedescribed in the model of the computing device. By way of yet anotherexample, a particular constraint on the workload may specify thesoftware licensing requirements for various types of deployment, whereoperating systems and applications would have different rules about thelicenses required when deploying the workload on a processor, or on ablade with many processors, or across several blades. Under these typesof constraints, a particular computing device may not have enoughlicenses to allow the workload to be deployed, even though it may haveenough processing power, memory and storage.

Oftentimes, the model of the system built in act 704 will be generatedby the system administrator prior to the workload being designed and themodel of the workload being built in act 702. In such situations, thepreviously generated model can be accessed and need not be re-built inact 704.

Components in the model of the system built in act 704 will includeconstraint information pages. These constraint information pages includeconstraints for each component in the virtual system. Such constraintinformation pages can identify constraints for the correspondingcomponent, and optionally constraints that should be satisfied by anyapplication to be installed on the corresponding component. Both theconstraints on the workload and the characteristics of the system may betime-series data, in addition to the possibly time-based nature of thedeployment schedule. For example, if once started the workload requiresonly 1 CPU for half an hour, and then needs 4 CPUs for half an hour,this sequence of values can be represented in the constraints.Similarly, if a computing device has 8 CPUs, but 2 of them are assignedto a workload for 1 hour, and 4 of them are assigned to a workload for 3hours, and after that no more work is assigned to the computing device,the number of available CPUs can be calculated as 2 CPUs for 1 hour, 4CPUs for 2 hours after that, and 8 CPUs after that. This time series ofavailable CPUs can be recorded in the characteristics page of the systemmodel

Based on the models built in acts 702 and 704, a logical deploymentevaluation is performed (act 706). The logical deployment evaluationinvolves comparing the model of the workload (from act 702) to the modelof the system (from act 704) to determine whether the application couldbe installed in the system. Typically, the application designer orsystem administrator will identify a particular class (or classes) ofcomputing device on which he or she desires to install the application.Alternatively, the application may be compared to all classes ofcomputing devices in the system.

The constraints and/or description information for the workload arecompared to the constraints for that class of computing device todetermine whether the workload satisfies the constraints of the class ofcomputing device, and the constraints and/or description information forthe class of computing device are compared to the constraints for theworkload to determine whether the class of computing device satisfiesthe constraints of the workload. The constraints and descriptioninformation for all components of the class of computing device,including any applications that are hosted by the class of computingdevice (e.g., an operating system as well as possibly otherapplications) are also accessed as part of the logical deploymentevaluation. These constraints used in the logical deployment evaluationcan include constraints that are flowed across relationships, asdiscussed above. These constraints used in the logical deploymentevaluation can also include time-series based constraints, as discussedabove. Accessing the constraints for the operating system and otherapplications allows verification that, if installed on a device of theclass of computing device, settings made on the computing device for theworkload would not conflict with current settings for other applicationsinstalled on the computing device. The verification can use thescheduled start time of the workload, and the time-series of constraintsand system characteristics, and can verify that the time profile ofresources available on the system satisfies the time profile ofrequirements of the workload. In embodiments in which a virtual machineis being installed onto which the application will be installed, theevaluation in act 706 includes evaluating that any constraints of thevirtual machine are satisfied by the class of computing device in orderto verify that the virtual machine can be installed on the class ofcomputing device.

By way of example, a particular constraint on the class of computingdevice may indicate that a software firewall should always be running onthe class of computing device. A description page associated with theworkload would be accessed to verify that the workload does not requirea software firewall to be deactivated.

By way of another example, a particular constraint on the workload mayindicate that the computing device should have a minimum processorspeed. A description page associated with the class of computing device(or the processor of the class of computing device) would be accessed toverify that the speed of the processor is at least the minimum processorspeed. As discussed above, this processor speed could refer to the speedof the virtual processor of the virtual machine on which the workloadwould be installed, or the speed of the physical processor of the classof computing device on which the virtual machine is installed.Furthermore, the fractional parts of the physical processor may beallocated to each virtual machine, and each such fractional part servesas the virtual processor for the virtual machine to which the part isallocated. As a fractional part of the physical processor could not beallocated as a virtual processor with a faster speed than the physicalprocessor, a check would be made to ensure that the speed of thephysical processor satisfies the constraint. Furthermore, a check wouldalso be made that the fractional part of the physical processor can beallocated to the virtual machine to create a virtual processor thatsatisfies the constraint. This check can be performed by checking adescription page associated with the system, or by communicating arequest or query to a virtual system management component as to whetherit would be able to create such a virtual machine having a virtualprocessor satisfying the constraint. It is to be appreciated that suchspeeds of virtual processors can vary depending on the number of othervirtual machines that are already running on the computing device, asthe presence of such other virtual machines will affect the fractionalpart of the physical processor that can be allocated to the virtualmachine.

By way of yet another example, a particular constraint on the workloadmay indicate that the computing of the workload should be performedbetween midnight and 4:00 am. A description page associated with theclass of computing device would be accessed to verify that the computingdevice has sufficient processing capacity (in light of other workloadsalready scheduled to be performed between midnight and 4:00 am) to havea new virtual machine (or alternatively an existing virtual machine)perform the computing of the workload.

It should be noted that, depending on the manner in which virtualmachines are created and managed, it may be possible for a class ofcomputing device to “overcommit” its resources. For example, threedifferent virtual machines may each require 4 GB of memory, but aparticular class of computing device may only have 8 GB of memory. Insuch situations, all three virtual machines could be run on that classof computing device by running only two of the three virtual machinesconcurrently, or all three virtual machines could be run simultaneously(on the assumption that the workloads will on the average share somememory pages that are used for read-only access). By way of anotherexample, two different virtual machines may each require 100 GB ofstorage space, but a particular class of computing device may only have160 GB of storage space. In such situations, both virtual machines couldbe run on that class of computing device by running the two virtualmachines at separate times, or both virtual machines could be runsimultaneously (on the assumption that they will not both make fulldemands on the storage space at the same time). The models of theworkloads indicate whether such overcommitment is possible and whetherit is desirable.

It should also be noted that whatever components are referenced byconstraints in the SDM are evaluated in act 706, regardless of whatthose components are. Typically, constraints of the class of computingdevice are evaluated in act 706 down to the layer that is hosting theworkload being installed, but may extend to other layers if referencedin the SDM. By way of example, assume that a virtual machine is beingprovisioned on a computing device, and a workload is being provisionedon the virtual machine. Typically, constraints of the virtual machinewould be evaluated against the computing device and the operating systemrunning on the computing device, while constraints of the workload wouldbe evaluated against the virtual machine. However, if the workload had aconstraint referencing the computing device itself (e.g., regardingphysical protection of the computing device on which the workload isdeployed), then that constraint of the workload would be evaluatedagainst the computing device.

The results of the evaluation in act 706 can be returned to the workloaddesigner and/or system administrator. An indication of success (if allof the constraints are satisfied) or failure (if all of the constraintsare not satisfied) can be returned. In addition, if one or more of theconstraints are not satisfied, then an indication of which constraintwas not satisfied can be returned, as well as optionally an indicationof which component caused the constraint to not be satisfied.Optionally, the evaluation can indicate whether the constraints thatwere not satisfied were mandatory or recommended constraints. Returningsuch information can assist the workload developer in modifying theworkload so that it can be installed in the system, and in choosingwhich of the available systems would be most suited for the workload.

Process 700 then proceeds based on the results of the evaluation in act706. If the evaluation indicates that the workload can be installed inthe system, then process 700 can proceed to act 708. Act 706 may alsooptionally be repeated for a different class of computing device in thesystem. However, if the evaluation indicates that the workload cannot beinstalled in the system, then the evaluation of act 706 can be repeatedfor a different class of computing device in the virtual system, oralternatively the workload may be modified in order to overcome theproblem(s) identified in the evaluation of act 706, and process 700 canreturn to act 702 to build a model of the modified workload. Iftime-series based constraints are not met by the system, and if thescheduled start time is specified as a recommended rather than requiredstart time, the verification can evaluate whether the constraints can bemet by a later or earlier start time and can return a list of possibleclasses of computing devices with the possible start time for each one.

In act 708, physical deployment of the workload is determined.Determining physical deployment of the workload refers to identifyingwhich particular computing device(s) will perform the computing of theworkload (and optionally have a new virtual machine created thereon toperform the computing of the workload). The particular computingdevice(s) which will perform the computing of the workload can beidentified in different manners. One way in which the particularcomputing device(s) will perform the computing of the workload can beidentified is manually, such as by a system administrator or other partymanually selecting a particular computing device(s). This manuallyselected computing device(s) could be a computing device already(s) inthe system, or alternatively a new computing device(s) that needs to bepurchased or a computing device(s) that needs to be removed from storageand added to the system (e.g., coupled to the network that the othercomputing devices in the system are coupled to).

Alternatively, the particular computing device(s) which will perform thecomputing of the workload can be identified automatically. Anapplication running in the system can identify various characteristicsof the computing devices on which a virtual machine could be created andthe workload installed thereon (e.g., the computing devices of theparticular class of computing device on which the application is to beinstalled), such as load characteristics of each computing device. Theload characteristics could identify, for example, the average or maximumamount of processor usage, the average amount of memory usage, theamount of available network bandwidth being used, the amount of harddisk drive space being used, and so forth. Based on these loadcharacteristics, the computing device(s) most likely to be able tosupport the new virtual machine and the workload would be identified asthe computing device(s) on which the computing of the workload is to beperformed (e.g., the computing device having the lightest load, such asthe lowest average processor usage, the smallest amount of availablenetwork bandwidth being used, the most hard disk drive space available,and so forth). If no computing device can meet the recommended schedule,but several can meet the required schedule, the computing device thatcomes closest to meeting the recommended schedule could be identified.

It should be noted that typically a new virtual machine is created aspart of installing the workload. Thus, the characteristics of thecomputing devices are evaluated for purposes of determining whichcomputing device(s) will have the new virtual machine created thereonand will perform the computing of the workload. Alternatively, a newvirtual machine may not be created, and the workload may be installed onan already running virtual machine. In such situations, thecharacteristics of the currently running virtual machines are evaluatedfor purposes of determining which virtual machine(s) will perform thecomputing of the workload.

Alternatively, the particular computing device(s) which will perform thecomputing of the workload can be identified in a semi-automatic manner.An application running in the system can identify variouscharacteristics of the computing devices on which the virtual machinecould possibly be created and the computing of the workload couldpossibly be performed (or characteristics of the virtual machines onwhich the workload could possibly be performed) analogous to theautomatic manner, and then present those results to a user (such as thesystem administrator) for manual selection of one or more of thecomputing devices (or virtual machines). One or more of the computingdevices may optionally be recommended to the user as the bestcandidate(s) for selection, but the ultimate selection would remain atthe user's discretion.

Additionally, priorities of different workloads may be used as part ofthe physical deployment determining of act 708. Workloads can optionallybe assigned priorities, allowing the importance of the workloadsrelative to one another to be identified. These priorities are typicallyincluded in the model of the workload or the workload itself, butalternatively may be maintained elsewhere. Higher priority workloads canbe given access to resources of the virtual system before lower priorityworkloads. This can result in situations where, for example, higherpriority workloads can be performed by a computing device(s), but thereare insufficient resources for lower priority workloads to be performed.This can also result in situations where, for example, higher priorityworkloads are given the resources recommended by the constraints of theworkload, whereas lower priority workloads are given only the resourcesrequired by the constraints of the workload.

In addition, selection of different sources of data and/or other systemsto which access is needed may be performed as part of the physicaldeployment determining of act 708. For example, multiple sources mayexist from which data identified as being required in the model of theworkload can be obtained, or multiple replicated file servers may existthat can be a file server identified as being required in the model ofthe workload. Particular sources of data and/or other systems to whichaccess is needed may be selected in act 708 based on various factors,such as the load on the various sources and/or other systems, thebandwidth of the connection to those sources and/or systems, and soforth. Alternatively, rather than being performed as part of act 708,selection of such sources of data and/or other systems to which accessis needed may be performed as part of the physical deployment in act 712discussed below.

It should be noted that one additional factor that can be optionallytaken into account when identifying the characteristics of the variouscomputing devices is that virtual machines can be rearranged to run ondifferent computing devices. For example, a virtual machine running onone computing device could be moved to another computing device, therebyfreeing up capacity on the original computing device. Such a process ofmoving or rearranging virtual machines is also referred to as migrationof the virtual machines. Virtual machines can be migrated in any of avariety of manners, such as with the assistance of the Virtual ServerMigration Toolkit (VSMT) available from Microsoft Corporation ofRedmond, Wash.

Accounting for the possibility of migrating virtual machines allows theload characteristics of the computing devices to be changed by migratingthe virtual machines. For example, the situation may arise where none ofthe computing devices have the desired spare capacity to create avirtual machine on which the application could be installed, but thatcapacity of one of the computing devices could be released by moving avirtual machine from that one computing device to another of thecomputing devices. After the virtual machine is moved, however, thereleased capacity results in that one computing device having sufficientcapacity so that the new virtual machine on which the application is tobe installed can be created and the application installed on that newvirtual machine.

This identification of which computing device should perform thecomputing of the workload, and optionally which virtual machines shouldbe migrated to different computing devices, is performed as part of thephysical deployment determining of act 708.

A workload installation specification for physical deployment of theworkload is then generated (act 710). The workload installationspecification can be saved as an installation page associated with thecomponent representing the workload in the workload model. The workloadinstallation specification includes an identification, for each class ofdevice in the virtual system on which the workload may be installed, ofhow to install the workload. As each of these identifications indicateshow to install the workload on a particular class of devices, theseidentifications can also be referred to as device class installationspecifications. The device class installation specifications can alsoidentify which particular computing device(s) of that class the workloadis to be installed on (the computing device(s) determined in act 708).

This identification of how to install the workload includes, forexample, all of the settings for the virtual machine to be created onthe device, the operating system to install on the virtual machine(including all of the settings of the operating system and theidentification of all of the files that need to be copied to the virtualmachine to install the operating system), all of the settings of thecomputing device that should be made or changed, an identification ofall of the files that need to be copied to the computing device andwhere those files should be copied, an order in which files should becopied and/or settings made or changed, any initialization programs thatneed to be run after the files have been copied and/or settings made orchanged, and so forth. This identification may also include installingan operating system and/or one or more additional applications on thecomputing device prior to creating the virtual machine on the device.For example, one class of computing device may be a bare computingdevice with no operating system installed on it. In such situations, theinstallation specification for that class of computing device wouldinclude initially installing the appropriate operating system on thecomputing device, followed by creating the virtual machine on thecomputing device, then installing an operating system on the virtualmachine, and then installing the application on that operating system ofthe virtual machine.

In certain implementations, this identification of how to install theworkload identifies a particular image file that is the image to be runto perform the computing of the workload. The image file can be createdas part of the process of building the model of the workload in act 702,or alternatively can be created at other times (e.g., after the logicaldeployment evaluation has been performed in act 706). The image fileincludes the application files and data, and optionally the files anddata for the operating system on which the application will be executed,for the workload. The image file can be copied to a disk drive or otherstorage device and executed by a virtual machine to perform thecomputing of the workload—no additional installation or configuration ofthe operating system or the application of the workload is typicallyrequired. The image file can be generated in any of a variety ofconventional manners, such as by installing the application andoperating system onto a virtual machine and generating a file thatincludes all the folders and files installed onto that virtual machine,by a user (e.g., the designer of the workload) manually identifying thefolders and files to be included in the image file, and so forth. Theimage file can then be simply copied to the computing device(s) as partof the physical deployment in act 712 discussed below.

Additionally, if any migration of virtual machines is to be performedfor a particular class of device, as identified in act 708, then thedevice class installation specification for that class of deviceincludes an indication of the migration that is to be performed and theconstraints that must be met for that type of migration.

At least a portion of each device class installation specification canbe generated automatically based on the information contained in theinformation pages associated with the workload to be installed. Asdiscussed above, the constraint information page can include variousdefault values. These default values can be used during act 710 toidentify the settings or configuration values that should be set wheninstalling the workload, and thus which should be included in the deviceclass installation specification. For example, a particular defaultvalue may be included in the configuration information page for a buffersize. This default value would be included in the device classinstallation specification so that when the workload is installed on aparticular computing device, the computing device settings (such as inan operating system registry) can be modified to include this defaultvalue for the buffer size (possibly replacing another value for thebuffer size previously stored in the computing device settings).

In addition to default values, other constraint information included inthe constraint information page can be used in act 710 to identify thesettings or configuration values that should be set when installing theworkload. If a range of values for a particular setting were included inthe constraint information page, then a setting to be used wheninstalling the application can be derived from that range. For example,the lowest value in the range could be selected, the highest value inthe range could be selected, the average of the highest and lowestvalues in the range could be computed and selected, a value in the rangecould be selected randomly, and so forth.

Furthermore, in addition to information contained in the informationpages associated with the workload, information contained in theinformation pages associated with the virtual system (such as thecomputing device on which the application is to be installed) can beused as a basis for automatically generating at least a portion of eachdevice class installation specification. Default values and/or ranges ofvalues can be used to automatically generate values for the device classinstallation specification in the same manner as discussed above.

It should also be noted that different components can have differentconstraints and different default values for the same settings orconfiguration values. In such situations, even though there is overlapof the constraints so that the different components can all be installedon a computing device, one or more of the default values may violate theconstraints of another component. Thus, a suitable value that iscompliant with the constraints of all of the components is determined.This suitable value can be determined in different manners, includingmanually, automatically, and semi-automatically. A suitable value can bedetermined manually by a user (such as the system administrator)inputting a suitable value for the setting or configuration value.

A suitable value can be determined automatically by evaluating thevarious constraints and selecting a value that satisfies all theconstraints. This selected value is then used as the suitable value. Forexample, if each constraint lists a range of acceptable values, then avalue that falls within each range of acceptable values can beautomatically identified and used as the suitable value.

A suitable value can be determined semi-automatically by evaluating thevarious constraints and selecting a value that satisfies all theconstraints analogous to the automatic manner. However, rather thanautomatically using the selected value as the suitable value, theselected value can be presented to a user (such as the systemadministrator) for approval. The user can accept this selected value, oralternatively input a different value. Alternatively, rather thanpresenting a single selected value to the user, the range of possiblevalues (or portion of the range of possible values) that satisfies theconstraints of the different components may be presented to the user.

It should further be noted that at least a portion of a device classinstallation specification may be generated manually rather thanautomatically. This manual generation refers to user inputs (such as bythe application developer or system administrator) rather than automaticgeneration by some component or module (e.g., development module 800discussed below). For example, the particular files to be identified inthe device class installation specification may be identified manuallyrather than automatically.

Additionally, an assignment record is generated in act 710 thatmaintains a record of which device class installation specifications areto be used for which device classes. This record can be, for example, amapping of device class to device class installation specification.Thus, given the workload installation specification including multipledevice class installation specifications, a determination as to whichparticular device class installation specification to use can be madebased on the class of the device on which the workload is to beinstalled. The assignment record generated can also be stored as part ofthe workload installation specification.

Alternatively, rather than having a separate assignment record, anidentification of which device class installation specification isassociated with which particular class of device may be maintained inother manners. For example, the indication may be inherent in the namingconvention used for the device class installation specification (e.g.,each device class installation specification may be a separate filehaving a file name that identifies the particular class of device), oreach device class installation specification may include an indicationof the associated class of device.

The workload installation specification is generated after the logicaldeployment evaluation in act 706. Thus, the application installationspecification is generated only after it is verified that the workloadcan be installed in the system. Additionally, the constraint information(such as default values) associated with the workload can be used todetermine settings to be included in the workload installationspecification. Thus, it can be seen that the workload installationspecification generated in act 710 is derived at least in part from themodel of the workload as well as the model of the system.

After the workload installation specification is created, physicaldeployment of the workload is performed (act 712). The timing of thephysical deployment can vary. Deployment may be triggered manually, suchas by a user (such as the system administrator) specifying thatdeployment should begin “now” or at a particular time in the future.Deployment may also be triggered based on other events and/or schedulesidentified in the workload as discussed above.

In certain implementations, this physical deployment includes making theworkload installation specification available to a deployment system andhaving the deployment system create a new virtual machine on theparticular device identified in act 708, and also copy the image fileidentified by the workload on the particular device identified in act708 for execution by the newly created virtual machine. In otherimplementations, this physical deployment includes making the workloadinstallation specification available to a deployment system and havingthe deployment system create a new virtual machine on the particulardevice identified in act 708 and install the application on that newvirtual machine following the installation instructions in the workloadinstallation specification.

Once the deployment system is given the workload installationspecification, the deployment system operates in a conventional mannerto install the workload. If the application installation specificationindicates that migration of any virtual machines is to be performed,then this migration can also be carried out by the deployment system(optionally with the assistance of another component, such as theVirtual Server Migration Toolkit discussed above). Any of a variety ofdeployment systems could be used in act 712, such as the Windows®Installer service or Microsoft® Systems Management Server, bothavailable from Microsoft Corporation of Redmond, Wash.

Once the workload is installed on a computing device, the new virtualmachine and the application installed thereon becomes part of the systemand thus the workload model is incorporated into the system model and acomponent for the new virtual machine (as well as the operating systemfor the new virtual machine, and any other components running on thevirtual machine) is added to the system model. Thus, after installationof the application, the SDM for the system includes the SDM of theworkload. This includes modifying characteristics of the system such asavailable number of CPUs, which might be time-series based to reflectthe allocation of CPUs to scheduled workloads and the time-series basedrequirements of CPUs of those workloads.

Alternatively, the evaluation in act 706 may be for a particularcomputing device or virtual machine rather than for a class of computingdevice. In this alternative, the evaluation in act 706 is the same asdiscussed above, except that constraint and description information fora particular instance of a computing device are used rather thanconstraint and description information for a class of computing device.In such situations, the identification of the particular computingdevice is made in, or prior to, act 706 rather than in act 708, and canbe made in the same manner as discussed in act 708.

It should also be noted that a particular device class installationspecification may indicate to install the whole workload or individualcomponents of the workload on multiple different computing deviceswithin the system. For example, the workload developer or systemadministrator may desire to install the workload on all of the computingdevices of a particular class. By way of another example, the workloaddeveloper or system administrator may desire to install each part of theworkload on a computing device of a specific class. In such a situation,an indication is included in the device class installation specificationfor that particular device class that the workload is to be installed onall of the computing devices of that particular class, or alternativelymay identify the particular computing devices (e.g., by name or otherunique identifier) on which the workload is to be installed. Theinstallation instructions may also identify the sequence in which theparts of the workload are to be installed on each system, and how tocoordinate the installation steps by waiting for the completion of onestep before proceeding with the next, using conventional orchestrationtechnologies. The deployment system used to install the workloadreceives this indication and installs the workload on the appropriatecomputing devices.

FIG. 8 illustrates an example workload installation specification inadditional detail. An installation specification development module 800generates a workload installation specification 802. Installationspecification module 800 can be implemented in software, firmware,hardware, or combinations thereof, and can perform act 710 of FIG. 7,and optionally additional acts of FIG. 7 (such as act 706 and/or act708). Workload installation specification 802 includes multiple (x)device class installation specifications 804(1), 804(2), . . . 804(x).Each of the device class installation specifications 804 identifies howthe workload is to be installed on a particular class of computingdevice. Workload installation specification 802 also includesspecification assignment record 806 to identify which specification 804corresponds to which class of computing device.

Workload installation specification 802 is input to a deployment system808 along with any necessary installation file(s) 810. Installationfile(s) 810 include the file(s) that are to be installed on thecomputing device in order to install the application, such as one ormore files of executable code, one or more files of data, an image file,and so forth. Alternatively, although illustrated separately, workloadinstallation specification 802 and installation file(s) 810 may bestored together in a single package (e.g., a compressed file).

FIG. 9 is a flowchart illustrating the generation of a workloadinstallation specification for physical deployment of act 710 of FIG. 7in additional detail. FIG. 9 can be implemented in software, firmware,and/or hardware.

Initially, a device class on which the workload could be installed isselected (act 902). In certain embodiments the system administratorand/or workload developer (or alternatively some other party) may desirethat the workload be installed only on certain classes of devices, inwhich case the devices on which the workload could be installed is lessthan all of the devices in the system. Alternatively, the workload maybe able to be installed on any device in the system.

A device class installation specification for the selected device classis then generated, identifying how to install the workload and virtualmachine on the selected device class (act 904). As discussed above, thisgeneration can include using default values included in an informationpage associated with the workload in the workload model for settingvalues to include in the installation specification being generated.

In some situations, the device class installation specification isgenerated in a format that is expected and understood by a deploymentsystem that will be installing the workload and the virtual machine. Thedevice class installation specification may be generated in this formatin act 904, or alternatively may be subsequently translated into thisformat (e.g., by a translation component of the distribution system).

It should be noted that different device installation specifications maybe generated for computing devices that will have the same functionalitybut are currently configured differently, such as computing devices thatdo not yet have an operating system installed and computing devices thatalready have an operating system installed. Alternatively, suchcomputing devices may be considered to be part of the same device class,but the device class installation specification would include aconditional portion to be used based on the configuration of theparticular instance of the computing device on which the application isbeing installed (e.g., the conditional portion may be bypassed if thecomputing device already has an installed operating system, or used toinstall an operating system on the computing device if an operatingsystem is not already installed on the computing device).

A check is then made as to whether there are any additional deviceclass(es) in the virtual system for which no device class installationspecification has been generated (act 906). If there are any suchadditional device class(es), then one such additional device class isselected (act 908) and the process returns to act 904 to generate adevice class installation specification for the selected device class.

Returning to act 906, if device class installation specifications havebeen generated for all of the device class(es), then a specificationassignment record is generated associating particular installationspecifications with particular device classes (act 910). Alternatively,the specification assignment record may be generated in act 904 as thedevice class installation specifications are being generated, and anindication of which device class is associated with which device classinstallation specification added to the specification assignment recordas the device class installation specification is generated.

The device class installation specifications generated in act 904 andthe assignment record generated in act 910 are then combined into aworkload installation specification for the application (act 912).

Test Environment Provisioning

FIG. 10 is a flowchart illustrating an example process 1000 forprovisioning a test environment. Portions of process 1000 can beimplemented in software, firmware, and/or hardware.

Initially, a model of the application to be installed on a system isbuilt (act 1002). This building process in act 1002 is typicallyperformed by the developer of the application, although couldalternatively be performed by others. This model is an SDM model of theapplication, analogous to model 100 of FIG. 1, and includes one or morecomponents. The model of the application includes types and optionallyconfigurations. As part of the building process in act 1002, zero ormore information pages are associated with each component in the model.Typically, at least a constraint information page is associated witheach component in the model.

As part of the building process in act 1002, types and optionallyconfigurations are defined, along with associated information page(s).The types and configurations can be standard types or configurationsthat are copied or modified in act 1002, or alternatively can be newlycreated in act 1002. As discussed above, different constraints can beincluded in the configuration information page associated with the typeand the configuration information page associated with theconfiguration.

The constraints included on a constraint information page can take avariety of forms, such as: hardware requirements regarding the computingdevice(s) or other hardware on which the application is to be installed(e.g., a minimum processor speed, a minimum amount of memory, a minimumamount of free hard drive space, a minimum amount of network bandwidthavailable, particular security mechanisms available, and so forth),software requirements regarding the computing device(s) or otherhardware or software on which the application is to be installed (e.g.,a particular operating system that should already be installed on thecomputing device(s), one or more other applications that should alreadybe installed on the computing device(s), specifications regarding howparticular hardware and/or the operating system is to be configured suchas particular settings for the operating system that should already bemade, a particular type of security or encryption that should be in use,and so forth), requirements regarding a virtual machine that should becreated on a computing device as well as requirements regarding anoperating system that should be installed on the virtual machine beforethe application can be installed thereon, other requirements regardingthe computing device(s) on which the application is to be installed(e.g., particular security keys available, data center policies thatshould be enforced, authentication that is used, system topology, etc.),and so on.

Constraints can be positive requirements specifying that somethingshould be present (e.g., the processor should have at least a minimumprocessor speed, or the Windows® XP operating system should already beinstalled on the computing device). Constraints can also be negativerequirements specifying that something should not be present (e.g., oneor more particular applications should not already be installed on thecomputing device, or particular operating system settings should not bepresent).

Additionally, a model of the system where the application is to beinstalled is built (act 1004). This building process in act 1004 istypically performed by an administrator of the system where theapplication is to be installed, although could alternatively beperformed by others. This model is an SDM model of the system analogousto model 100 of FIG. 1, and includes one or more components. The modelof the system includes types and instances, and optionallyconfigurations. As discussed in more detail below, for virtual systems anew virtual machine may be created onto which the application will beinstalled. As such, no instance for the virtual machine exists yet inthe model of the system. However, the computing device on which thevirtual machine will run may already exist, in which case an instance ofthat computing device is in the model of the system.

The system in act 1004 could be a single computing device, oralternatively multiple computing devices. For example, if theapplication will be installed on a computing device in a data centerhaving a thousand computing devices, then the model of the system wherethe application is to be installed may include all or some of thosethousand computing devices. By way of another example, if theapplication will be installed on a home computer that is not coupled toany other computers, then the model of the virtual system where theapplication is to be installed will include just that home computer.

It should also be noted that the exact nature of a computing device canvary, and that any of a wide variety of computing devices can be asystem in act 1004. For example, “hierarchical” computers can exist,such as a rack that can contain multiple chassis, each chassis cancontain multiple blades, each blade can contain multiple motherboards,each motherboard can contain multiple processors, and each processor cancontain multiple cores. Any of these components of such a hierarchicalcomputer can be viewed as a computing device (e.g., the rack can be acomputing device, each chassis can be a computing device, each blade canbe a computing device, each motherboard can be a computing device, eachprocessor can be a computing device, and/or each core can be a computingdevice).

Oftentimes, the model of the system built in act 1004 will be generatedby the system administrator prior to the application being designed andthe model of the application being built in act 1002. In suchsituations, the previously generated model can be accessed and need notbe re-built in act 1004.

Components in the model of the system built in act 1004 will includeconstraint information pages. These constraint information pages includeconstraints for each component in the system. Such constraintinformation pages can identify constraints for the correspondingcomponent, and optionally constraints that should be satisfied by anyapplication to be installed on the corresponding component.

Based on the models built in acts 1002 and 1004, a logical deploymentevaluation is performed (act 1006). The logical deployment evaluationinvolves comparing the model of the application (from act 1002) to themodel of the system (from act 1004) to determine whether the applicationcould be installed in the system. Typically, the application designer orsystem administrator will identify a particular class (or classes) ofcomputing device on which he or she desires to install the application.Alternatively, the application may be compared to all classes ofcomputing devices in the system.

The constraints and/or description information for the application arecompared to the constraints for that class of computing device todetermine whether the application satisfies the constraints of the classof computing device, and the constraints and/or description informationfor the class of computing device are compared to the constraints forthe application to determine whether the class of computing devicesatisfies the constraints of the application. The constraints anddescription information for all components of the class of computingdevice, including applications that are hosted by the class of computingdevice (e.g., an operating system as well as possibly otherapplications) are also accessed as part of the logical deploymentevaluation. These constraints used in the logical deployment evaluationcan include constraints that are flowed across relationships, asdiscussed above. Accessing the constraints for the operating system andother applications allows verification that, if installed on a device ofthe class of computing device, settings made on the computing device forthe application would not conflict with current settings for otherapplications installed on the computing device, and that the computingdevice has the characteristics, capabilities and resources required bythe application.

By way of example, a particular constraint on the class of computingdevice may indicate that a software firewall should always be running onthe class of computing device. A description page associated with theapplication would be accessed to verify that the application does notrequire a software firewall to be deactivated. By way of anotherexample, another application already installed on the class of computingdevice may indicate that memory in the computing device should beconfigured or accessed in a particular manner. A description pageassociated with the application would be accessed to verify that theapplication does not require configuration or access to the memory thatis inconsistent with that particular manner.

By way of yet another example, a particular constraint on theapplication may indicate that the computing device should have a minimumprocessor speed. A description page associated with the class ofcomputing device (or the processor of the class of computing device)would be accessed to verify that the speed of the processor is at leastthe minimum processor speed. In the case of a virtual machine, thisprocessor speed could refer to the speed of the virtual processor of thevirtual machine on which the application would be installed, or thespeed of the physical processor of the class of computing device onwhich the virtual machine is installed. Furthermore, the fractionalparts of the physical processor may be allocated to each virtualmachine, and each such fractional part serves as the virtual processorfor the virtual machine to which the part is allocated. As a fractionalpart of the physical processor could not be allocated as a virtualprocessor with a faster speed than the physical processor, a check wouldbe made to ensure that the speed of the physical processor satisfies theconstraint. Furthermore, a check would also be made that the fractionalpart of the physical processor can be allocated to the virtual machineto create a virtual processor that satisfies the constraint. This checkcan be performed by checking a description page associated with thevirtual system, or by communicating a request or query to a virtualsystem management component as to whether it would be able to createsuch a virtual machine having a virtual processor satisfying theconstraint. It is to be appreciated that such speeds of virtualprocessors can vary depending on the number of other virtual machinesthat are already running on the computing device, as the presence ofsuch other virtual machines will affect the fractional part of thephysical processor that can be allocated to the virtual machine.

By way of yet another example, a particular constraint on a workload mayindicate that the computing of the workload should be performed betweenmidnight and 4:00 am. A description page associated with the class ofcomputing device would be accessed to verify that the computing devicehas sufficient processing capacity (in light of other workloads alreadyscheduled to be performed between midnight and 4:00 am) to have a newvirtual machine (or alternatively an existing virtual machine) performthe computing of the workload.

It should be noted that whatever components are referenced byconstraints in the SDM are evaluated in act 1006, regardless of whatthose components are. Typically, constraints of the class of computingdevice are evaluated in act 1006 down to the layer that is hosting theapplication being installed, but may extend to other layers ifreferenced in the SDM. By way of example, assume that a virtual machineis being provisioned on a computing device, and an application is beingprovisioned on the virtual machine. Typically, constraints of thevirtual machine would be evaluated against the computing device and theoperating system running on the computing device, while constraints ofthe application would be evaluated against the virtual machine (and anyoperating system running on the virtual machine). However, if theapplication had a constraint referencing the computing device itself(e.g., regarding physical protection of the computing device on whichthe application is deployed), then that constraint of the applicationwould be evaluated against the computing device.

The results of the evaluation in act 1006 can be returned to theapplication designer and/or system administrator. An indication ofsuccess (if all of the constraints are satisfied) or failure (if all ofthe constraints are not satisfied) can be returned. In addition, if oneor more of the constraints are not satisfied, then an indication ofwhich constraint was not satisfied can be returned, as well asoptionally an indication of which component caused the constraint to notbe satisfied. Returning such information can assist the applicationdeveloper in modifying the application so that it can be installed inthe system, or identifying another system that may be better capable ofsupporting the test deployment of the application.

Process 1000 then proceeds based on the results of the evaluation in act1006. If the evaluation indicates that the application can be installedin the system, then process 1000 can proceed to act 1008. Act 1006 mayalso optionally be repeated for a different class of computing device inthe system. However, if the evaluation indicates that the applicationcannot be installed in the system, then the evaluation of act 1006 canbe repeated for a different class of computing device in the system, oralternatively the application may be modified in order to overcome theproblem(s) identified in the evaluation of act 1006, and process 1000can return to act 1002 to build a model of the modified application.

A model(s) of one or more test environments is also built (act 1008).The test environment includes at least some of the components (andoptionally all of the components) in the system for which the systemmodel is built in act 1004. This building process in act 1008 istypically performed by an administrator of the system where theapplication is to be tested, although could alternatively be performedby others. The system where the application is to be tested can be thesame as the system where the application is to be installed and used byone or more end users, although typically it is a different system. Eachof these models is an SDM model of a test environment analogous to model100 of FIG. 1, and includes one or more components. Each model of a testenvironment includes types and instances, and optionally configurations.

A test environment is a system, and the model of a test environment issimilar to the model of a system discussed above in act 1004. However, atest environment is typically expected to have a shorter lifespan thanother systems. The test environment is created for the purpose oftesting an application(s), and then the machines in the test environmentare typically re-provisioned for other uses.

Different test environments can be created for an application in orderto test different characteristics and/or functionality of anapplication. For example, one test environment may have a singlecomputing device on which the application is to be installed in order totest the functionality of the computing device. By way of anotherexample, another test environment may have 20 or 30 computing devices onwhich the application is to be installed in order to test theperformance or scalability of the application.

The model for the application to be tested can include constraints thatspecify a range of values that should be used during testing. Forexample, the memory for the application could be specified as rangingfrom 512 MB to 4096 MB in increments of 512 MB. Acts 1010 through 1016of process 1000 are then repeated for each such configuration. Ifsufficient computer resources are available, several test systems can beprovisioned at the same time and several tests executed in parallel. Ifsufficient resources are not available for such a parallel test, thevarious configurations are queued and provisioned sequentially.Combinations of parallel and sequential provisioning are also possible.

The model for the application to be tested can also includespecifications that certain values should be randomized. For example,the size of data files that are to be used when testing a backup utilitycan be set to a random set of values and the tests executed ten timeswith the different values. This can be useful because, for example, iteliminates systematic bias in the testing, helping ensure that a trulyrepresentative set of tests are run.

In order to reduce the cost of provisioning the test environment, suchas the network bandwidth required to send applications and operatingsystems to the computer systems employed in the test environment,process 1000 can take into account the amount of change required totransition from one test environment to another and sequentiallyprovision the test environments in a way that reduces that cost. Thesame technique can be applied when provisioning a single testenvironment, or the first test environment in a sequence, by evaluatingexisting environments that have been used for other purposes andidentifying which one would require the least amount of provisioningwork. This analysis of the amount of change required is based on simplecomparisons of the attributes of the systems in the model, both theapplication model and the test environment model.

A test environment can optionally be a virtual system. In the case of avirtual system, the test environment can describe one or more newvirtual machines onto which the application is to be installed. As such,no instance for the virtual machines exist yet in the model of the testenvironment. However, the computing device on which the virtual machinewill run may already exist, in which case an instance of that computingdevice is in the model of the test environment.

In act 1010, physical deployment of the application to one of the testenvironment(s) is determined. Determining physical deployment of theapplication to the test environment refers to identifying whichparticular computing device(s) in the test environment will have theapplication installed thereon (and optionally also have a new virtualmachine created thereon). This physical deployment can also take intoaccount the amount of change required to transition from one testenvironment to another as discussed above. As part of act 1010, whichcomputing device(s) in the system are to have the test environmentcreated thereon can also be identified. Such computing device(s) can beidentified in the same manner as the particular computing device onwhich the application is to be installed is determined as discussedbelow (such as manually, automatically, semi-automatically).

The particular computing device(s) on which the application is to beinstalled can be identified in different manners. One way in which theparticular computing device(s) on which the application is to beinstalled can be identified is manually, such as by a systemadministrator or other party manually selecting a particular computingdevice(s). This manually selected computing device(s) could be acomputing device(s) already in the system, or alternatively a newcomputing device(s) that needs to be purchased or a computing device(s)that needs to be removed from storage and added to the system (e.g.,coupled to the network that the other computing devices in the systemare coupled to).

Alternatively, the particular computing device(s) on which theapplication is to be installed can be identified automatically. Anapplication running in the system can identify various characteristicsof the computing devices on which the computer could possibly beinstalled (e.g., the computing devices of the particular class ofcomputing device on which the application is to be installed), such asload characteristics of each computing device. The load characteristicscould identify, for example, the average or maximum amount of processorusage, the average amount of memory usage, the amount of availablenetwork bandwidth being used, the amount of hard disk drive space beingused, and so forth. Based on these load characteristics, the computingdevice(s) most likely to be able to support the application would beidentified as the computing device(s) on which the application is to beinstalled (e.g., the application having the lightest load, such as thelowest average processor usage, the smallest amount of available networkbandwidth being used, the most hard disk drive space available, and soforth).

In situations where the application is installed on a virtual machine,typically a new virtual machine is created on which the application willbe installed. Thus, the characteristics of the computing devices areevaluated for purposes of determining which computing device will havethe new virtual machine installed. Alternatively, a new virtual machinemay not be created, and the application may be installed on an alreadyrunning virtual machine. In such situations, the characteristics of thecurrently running virtual machines are evaluated for purposes ofdetermining which virtual machine will have the new applicationinstalled on it.

Alternatively, the particular computing device(s) on which theapplication is to be installed can be identified in a semi-automaticmanner. An application running in the system can identify variouscharacteristics of the computing devices on which the application couldpossibly be installed (or characteristics of the virtual machines onwhich the application could possibly be installed) analogous to theautomatic manner, and then present those results to a user (such as thesystem administrator) for manual selection of one or more of thecomputing devices (or virtual machines). One or more of the computingdevices may optionally be recommended to the user as the bestcandidate(s) for selection, but the ultimate selection would remain atthe user's discretion.

In addition, selection of different sources of data and/or other systemsto which access is needed may be performed as part of the physicaldeployment determining of act 1010. For example, multiple sources mayexist from which data identified as being required in the model of theapplication can be obtained, or multiple replicated file servers mayexist that can be a file server identified as being required in themodel of the application. Particular sources of data and/or othersystems to which access is needed may be selected in act 1010 based onvarious factors, such as the load on the various sources and/or othersystems, the bandwidth of the connection to those sources and/orsystems, and so forth. Alternatively, rather than being performed aspart of act 1010, selection of such sources of data and/or other systemsto which access is needed may be performed as part of the physicaldeployment in act 1014 discussed below.

It should be noted that one additional factor that can be optionallytaken into account when identifying the characteristics of the variouscomputing devices is that virtual machines can be rearranged to run ondifferent computing devices. For example, a virtual machine running onone computing device could be moved to another computing device, therebyfreeing up capacity on the original computing device. Such a process ofmoving or rearranging virtual machines is also referred to as migrationof the virtual machines. Virtual machines can be migrated in any of avariety of manners, such as with the assistance of the Virtual ServerMigration Toolkit (VSMT) available from Microsoft Corporation ofRedmond, Wash.

Accounting for the possibility of migrating virtual machines allows theload characteristics of the computing devices to be changed by migratingthe virtual machines. For example, the situation may arise where none ofthe computing devices have the desired spare capacity to create avirtual machine on which the application could be installed, but thatcapacity of one of the computing devices could be released by moving avirtual machine from that one computing device to another of thecomputing devices. After the virtual machine is moved, however, thereleased capacity results in that one computing device having sufficientcapacity so that the new virtual machine on which the application is tobe installed can be created and the application installed on that newvirtual machine.

When creating new virtual machines, this identification of whichcomputing device should have a virtual machine created thereon, andoptionally which virtual machines should be migrated to differentcomputing devices, is performed as part of the physical deploymentdetermining of act 1010.

An application installation specification for physical deployment of theapplication to the test environment is then generated (act 1012). Theapplication installation specification can be saved as an installationpage associated with the component representing the application in theapplication model. The application installation specification includesan identification, for each class of device in the test environment onwhich the application may be installed, of how to install theapplication. As each of these identifications indicates how to installthe application on a particular class of devices, these identificationscan also be referred to as device class installation specifications. Thedevice class installation specifications can also identify whichparticular computing device(s) of that class the application is to beinstalled on (the computing device(s) determined in act 1010).

This identification of how to install the application includes, forexample, all of the settings for a virtual machine to be created on thedevice, the operating system to install on the virtual machine(including all of the settings of the operating system and theidentification of all of the files that need to be copied to the virtualmachine to install the operating system), all of the settings of thecomputing device that should be made or changed, an identification ofall of the files that need to be copied to the computing device andwhere those files should be copied, an order in which files should becopied and/or settings made or changed, any initialization programs thatneed to be run after the files have been copied and/or settings made orchanged, and so forth. This identification may also include installingan operating system and/or one or more additional applications on thecomputing device prior to creating a virtual machine on the device. Forexample, one class of computing device may be a bare computing devicewith no operating system installed on it. In such situations, theinstallation specification for that class of computing device wouldinclude initially installing the appropriate operating system on thecomputing device, followed by creating the virtual machine on thecomputing device, then installing an operating system on the virtualmachine, and then installing the application on that operating system ofthe virtual machine.

It should be noted that this identification of how to install theapplication can include how to install the appropriate operating system,virtual machine, and/or other applications on the computing device(s) ina system in order to create the desired test environment. Once the testenvironment is created, the application can then be installed tocomputing device(s) and optionally virtual machine(s) in the testenvironment.

In situations where workloads are used, this identification of how toinstall the application identifies a particular image file that is theimage to be run to perform the computing of the workload. The image filecan be created as part of the process of building the model of theapplication in act 1002, or alternatively can be created at other times(e.g., after the logical deployment evaluation has been performed in act1006). The image file includes the application files and data, andoptionally the files and data for the operating system on which theapplication will be executed, for the workload. The image file can becopied to a disk drive or other storage device and executed by a virtualmachine to perform the computing of the workload—no additionalinstallation or configuration of the operating system or the applicationof the workload is typically required. The image file can be generatedin any of a variety of conventional manners, such as by installing theapplication and operating system onto a virtual machine and generating afile that includes all the folders and files installed onto that virtualmachine, by a user (e.g., the designer of the workload) manuallyidentifying the folders and files to be included in the image file, andso forth. The image file can then be simply copied to the computingdevice(s) as part of the physical deployment in act 1014 discussedbelow.

Additionally, if any migration of virtual machines is to be performedfor a particular class of device, as identified in act 1010, then thedevice class installation specification for that class of deviceincludes an indication of the migration that is to be performed.

At least a portion of each device class installation specification canbe generated automatically based on the information contained in theinformation pages associated with the software application to beinstalled. As discussed above, the constraint information page caninclude various default values. These default values can be used duringact 1012 to identify the settings or configuration values that should beset when installing the application, and thus which should be includedin the device class installation specification. For example, aparticular default value may be included in the configurationinformation page for a buffer size. This default value would be includedin the device class installation specification so that when theapplication is installed on a particular computing device, the computingdevice settings (such as in an operating system registry) can bemodified to include this default value for the buffer size (possiblyreplacing another value for the buffer size previously stored in thecomputing device settings).

In addition to default values, other constraint information included inthe constraint information page can be used in act 1012 to identify thesettings or configuration values that should be set when installing theapplication. If a range of values for a particular setting were includedin the constraint information page, then a setting to be used wheninstalling the application can be derived from that range. For example,the lowest value in the range could be selected, the highest value inthe range could be selected, the average of the highest and lowestvalues in the range could be computed and selected, a value in the rangecould be selected randomly, and so forth.

Furthermore, in addition to information contained in the informationpages associated with the application, information contained in theinformation pages associated with the system (such as the computingdevice on which the application is to be installed) can be used as abasis for automatically generating at least a portion of each deviceclass installation specification. Default values and/or ranges of valuescan be used to automatically generate values for the device classinstallation specification in the same manner as discussed above.

Additionally, information contained in the information pages associatedwith the test environment can be used as a basis for automaticallygenerating at least a portion of each device class installationspecification. Default values and/or ranges of values can be used toautomatically generate values for the device class installationspecification in the same manner as discussed above. Furthermore,information pages such as description pages can include identificationsof particular operating systems and/or other applications that are to bepart of the test environment. Each device class installationspecification can then have automatically added thereto identificationsof the appropriate files for the operating systems and/or otherapplications, as well as the proper settings for the operating systemsand/or other applications.

It should also be noted that different components can have differentconstraints and different default values for the same settings orconfiguration values. In such situations, even though there is overlapof the constraints so that the different components can all be installedon a system, one or more of the default values may violate theconstraints of another component. Thus, a suitable value that iscompliant with the constraints of all of the components is determined.This suitable value can be determined in different manners, includingmanually, automatically, and semi-automatically. A suitable value can bedetermined manually by a user (such as the system administrator)inputting a suitable value for the setting or configuration value.

A suitable value can be determined automatically by evaluating thevarious constraints and selecting a value that satisfies all theconstraints. This selected value is then used as the suitable value. Forexample, if each constraint lists a range of acceptable values, then avalue that falls within each range of acceptable values can beautomatically identified and used as the suitable value.

A suitable value can be determined semi-automatically by evaluating thevarious constraints and selecting a value that satisfies all theconstraints analogous to the automatic manner. However, rather thanautomatically using the selected value as the suitable value, theselected value can be presented to a user (such as the systemadministrator) for approval. The user can accept this selected value, oralternatively input a different value. Alternatively, rather thanpresenting a single selected value to the user, the range of possiblevalues (or portion of the range of possible values) that satisfies theconstraints of the different components may be presented to the user.

It should further be noted that at least a portion of a device classinstallation specification may be generated manually rather thanautomatically. This manual generation refers to user inputs (such as bythe application developer or system administrator) rather than automaticgeneration by some component or module (e.g., development module 1100discussed below). For example, the particular files to be identified inthe device class installation specification may be identified manuallyrather than automatically.

Additionally, an assignment record is generated in act 1012 thatmaintains a record of which device class installation specifications areto be used for which device classes. This record can be, for example, amapping of device class to device class installation specification.Thus, given the application installation specification includingmultiple device class installation specifications, a determination as towhich particular device class installation specification to use can bemade based on the class of the device on which the application is to beinstalled. The assignment record generated can also be stored as part ofthe application installation specification.

Alternatively, rather than having a separate assignment record, anidentification of which device class installation specification isassociated with which particular class of device may be maintained inother manners. For example, the indication may be inherent in the namingconvention used for the device class installation specification (e.g.,each device class installation specification may be a separate filehaving a file name that identifies the particular class of device), oreach device class installation specification may include an indicationof the associated class of device.

The application installation specification is generated after thelogical deployment evaluation in act 1006. Thus, the applicationinstallation specification is generated only after it is verified thatthe application can be installed in the system. Additionally, theconstraint information (such as default values) associated with theapplication, as well as information associated with the system and thetest environment, can be used to determine settings to be included inthe application installation specification. Furthermore, the applicationinstallation specification is generated for particular device class(es)that are present in the test environment and identified in the testenvironment model. Thus, it can be seen that the applicationinstallation specification generated in act 1012 is derived at least inpart from the model of the application as well as the model of thesystem and the model of the test environment.

After the application installation specification is created, physicaldeployment of the application to the test environment is performed (act1014). This physical deployment includes making the applicationinstallation specification available to a deployment system and havingthe deployment system install the application on the particulardevice(s) identified in act 1010, including installing any necessaryoperating systems and/or other applications for the test environment,and optionally creating a new virtual machine(s) on the particulardevice(s). If the application installation specification indicates thatmigration of any virtual machines is to be performed, then thismigration can also be carried out by the deployment system (optionallywith the assistance of another component, such as the Virtual ServerMigration Toolkit discussed above). Once it is given the applicationinstallation specification, the deployment system operates in aconventional manner to install the application. Any of a variety ofdeployment systems could be used in act 1014, such as the Windows®Installer service or Microsoft® Systems Management Server, bothavailable from Microsoft Corporation of Redmond, Wash.

Once the application is installed the application (and any newly createdvirtual machine) becomes part of the system and part of the testenvironment and thus the application model is incorporated into thesystem model and a component for any new virtual machine (as well as theoperating system for the new virtual machine, and any other componentsrunning on the virtual machine) is added to the system model. Similarly,the application model is incorporated into the test environment modeland a component for any new virtual machine (as well as the operatingsystem for the new virtual machine, and any other components running onthe virtual machine) is added to the test environment model. Thus, afterinstallation of the application, the SDM for the system includes the SDMof the application as well as a component(s) for any newly createdvirtual machine, and the SDM for the test environment includes the SDMof the application as well as a component(s) for any newly createdvirtual machine.

Once the application is installed one or more tests are run on theapplication in the test environment (act 1016). The exact nature ofthese tests can vary by application and based on the desires of theapplication developer. The tests can include fully automated tests,where one or more test programs provide input to the application andmonitor the performance of and/or outputs of the application.Additionally, the tests can include manual tests, where a systemadministrator or other user provides input to the application and/ormonitors outputs of the application.

Process 1000 continues based on the results of the tests that are run inact 1016. In some instances, the tests may indicate that changes to theapplication need to be made. These changes may be minor in nature andnot result in a change to the model of the application. However, if thechanges result in a change to the model of the application, then process1000 returns to act 1002 for a new model of the application to be built.Alternatively, additional tests in additional test environments may berun before the changes to the application are made, thus delaying thereturn to act 1002. It should be noted that, if only the application ischanged, then the model of the system need not be rebuilt in act 1004and the model of the test environment(s) need not be rebuilt in act1008; rather, the previously built system model and test environmentmodel(s) can be used.

If process 1000 does not return to act 1002 after act 1016, then a checkis made as to whether there are any additional test environments inwhich one or more tests are to be run (act 1018). If there are any suchtest environments, then process 1000 returns to act 1010 to determinephysical deployment to one of the test environments. However, if thereare no such test environments, then the testing process is complete (act1020).

Alternatively, the evaluation in act 1006 may be for a particularcomputing device or virtual machine rather than for a class of computingdevice. In this alternative, the evaluation in act 1006 is the same asdiscussed above, except that constraint and description information fora particular instance of a computing device are used rather thanconstraint and description information for a class of computing device.In such situations, the identification of the particular computingdevice is made in, or prior to, act 1006 rather than in act 1010, andcan be made in the same manner as discussed in act 1010.

It should also be noted that a particular device class installationspecification may indicate to install the application on multipledifferent computing devices within the test environment. For example,the application developer or system administrator may desire to installthe application on all of the computing devices of a particular class.In such a situation, an indication is included in the device classinstallation specification for that particular device class that theapplication is to be installed on all of the computing devices of thatparticular class, or alternatively may identify the particular computingdevices (e.g., by name or other unique identifier) on which theapplication is to be installed. The deployment system used to installthe application receives this indication and installs the application onthe appropriate computing devices.

FIG. 11 illustrates an example application installation specification inadditional detail. An installation specification development module 1100generates an application installation specification 1102. Installationspecification module 1100 can be implemented in software, firmware,hardware, or combinations thereof, and can perform act 1012 of FIG. 10,and optionally additional acts of FIG. 10 (such as act 1006, 1008 and/oract 1010). Application installation specification 1102 includes multiple(x) device class installation specifications 1104(1), 1104(2), . . .1104(x). Each of the device class installation specifications 1104identifies how the application is to be installed on a particular classof computing device. Application installation specification 1102 alsoincludes specification assignment record 1106 to identify whichspecification 1104 corresponds to which class of computing device.

Application installation specification 1102 is input to a deploymentsystem 1108 along with any necessary installation file(s) 1110.Installation file(s) 1110 include the file(s) that are to be installedon the computing device in order to install the application, such as oneor more files of executable code, one or more files of data, and soforth. Alternatively, although illustrated separately, applicationinstallation specification 1102 and installation file(s) 1110 may bestored together in a single package (e.g., a compressed file).

FIG. 12 is a flowchart illustrating the generation of an applicationinstallation specification for physical deployment to a test environmentof act 1012 of FIG. 10 in additional detail. FIG. 12 can be implementedin software, firmware, and/or hardware.

Initially, a device class in the test environment on which theapplication could be installed is selected (act 1202). In certainembodiments the system administrator and/or application developer (oralternatively some other party) may desire that the application beinstalled only on certain classes of devices, in which case the deviceson which the application could be installed is less than all of thedevices in the system. Alternatively, the application may be able to beinstalled on any device in the system.

A device class installation specification for the selected device classis then generated, identifying how to install the application (andoptionally a virtual machine) on the selected device class, as well ashow to install any operating system and/or other applications needed forthe test environment (act 1204). As discussed above, this generation caninclude using default values included in an information page associatedwith the application in the application model for setting values toinclude in the installation specification being generated.

In some situations, the device class installation specification isgenerated in a format that is expected and understood by a deploymentsystem that will be installing the application. The device classinstallation specification may be generated in this format in act 1204,or alternatively may be subsequently translated into this format (e.g.,by a translation component of the distribution system).

It should be noted that different device installation specifications maybe generated for computing devices that will have the same functionalitybut are currently configured differently, such as computing devices thatdo not yet have an operating system installed and computing devices thatalready have an operating system installed. Alternatively, suchcomputing devices may be considered to be part of the same device class,but the device class installation specification would include aconditional portion to be used based on the configuration of theparticular instance of the computing device on which the application isbeing installed (e.g., the conditional portion may be bypassed if thecomputing device already has an installed operating system, or used toinstall an operating system on the computing device if an operatingsystem is not already installed on the computing device).

A check is then made as to whether there are any additional deviceclass(es) in the test environment for which no device class installationspecification has been generated (act 1206). If there are any suchadditional device class(es), then one such additional device class isselected (act 1208) and the process returns to act 1204 to generate adevice class installation specification for the selected device class.

Returning to act 1206, if device class installation specifications havebeen generated for all of the device class(es), then a specificationassignment record is generated associating particular installationspecifications with particular device classes (act 1210). Alternatively,the specification assignment record may be generated in act 1204 as thedevice class installation specifications are being generated, and anindication of which device class is associated with which device classinstallation specification added to the specification assignment recordas the device class installation specification is generated.

The device class installation specifications generated in act 1204 andthe assignment record generated in act 1210 are then combined into anapplication installation specification for the application (act 1212).

Configuration Monitoring

Configuration policies are defined in terms of a model (e.g., a systemdefinition model as discussed herein) that represents the structure andtopology of the entire system. Defining configuration policies in termsof a model allows the configuration policies to easily adapt to changesin the system configuration. Additionally, systems and methods discussedherein can represent the hosting relationship between, for example, aSQL Server and the Windows® operating system, and then specify aconstraint that flows across that relationship. This relationship allowsthe system to determine and maintain applicability and handle conflicts.However, the configuration policy for the SQL Server does not refer tointernal details of the Windows® operating system. Thus, therelationship reduces the impact on the SQL Server policies when theWindows® operating system is modified. Systems and methods discussedherein can further provide for the reconciliation of multipleconflicting policies. For example, the SQL Server and other applicationsmay have different policies on how the Windows® operating system shouldbe configured. The described systems and methods resolve any differencesin these policies when it is possible to do so by finding compromisesettings that are compliant with all the policies. When such aresolution is not possible, the unresolvable conflict is identified andbrought to the attention of a user, such as an administrator, who canhandle the problem on a higher level, for example by deploying theapplications on other computer systems where there is no conflict.

The SDM contains static information (e.g., the topology of softwareservices within an application) and dynamic information (e.g., thecontrol flow of a particular transaction). This information is used todescribe components, system architecture, and transaction flows (e.g., aseries of steps that perform a function).

Configuration management is important to allow an administrator tomonitor configuration settings and identify potential problems withvarious configuration changes. Systems and methods discussed herein canvalidate the compliance of systems (and components) with a prescribedconfiguration and report any violations of this prescribedconfiguration. The prescribed configuration may represent a secureconfiguration, thereby minimizing vulnerability to attack, or it mayrepresent a configuration desired by an IT (Information Technology)department to maintain consistency and reduce support costs. Informationcontained in the SDM is used to provide a context for the configurationsettings, such as the components or applications with which the settingsare associated and the relationships between the components andapplications in the system.

The systems and methods described herein inspect the configuration ofone or more components or systems, and compare the configuration(s) withthe prescribed configuration policy. Different configuration policiescan be associated with different components or systems based on, forexample, organizational groups or departments, geography, type ofcomponent or system, and the like.

FIG. 13 is a flowchart illustrating an example process 1300 for managingand monitoring the configuration of a system. Process 1300 can beimplemented in software, firmware, and/or hardware. Initially, process1300 identifies models associated with one or more applications (act1302). An application model can identify any number of configurationsettings or constraints associated with the application. In oneembodiment, the configuration settings or constraints are defined by adeveloper of the application. Example configuration settings includebuffer sizes, acceptable data formats, acceptable application oroperating system versions, and a setting indicating whether a firewallis activated. Constraint information can be contained in, for example, aconstraint page of the type discussed above with respect to the SDM.Process 1300 continues by identifying a model associated with the system(act 1304). In one embodiment, this model is an SDM model of the typediscussed above with respect to FIGS. 1 and 2.

After identifying one or more application models and a system model, theprocess deploys the logical and physical portions of the system (act1306). This deployment of the system “activates” the system and definesinterrelationships between the various components and applications inthe system. Although it is common that the process includes deploymentof the system based on the model, in certain embodiments the system maybe deployed in other ways, with or without reference to the model. Suchdeployment may have occurred well before the model-based configurationmanagement process is started, and before the model was created. Inthese embodiments, act 1306 may be omitted from the process.

The process continues by creating a configuration policy associated withthe system (act 1308). In a particular embodiment, the configurationpolicy is created automatically based on the system model and theconfiguration settings associated with the components and theapplications. A system may have configuration constraints ordependencies on related systems. For example, if a particularapplication is installed in the system, it may have a dependency onanother system and may require a specific configuration setting on thatother system. A “dependency” is also referred to as a “relationship.”

In one embodiment, the process extracts the desired information from thesystem model and discards the remaining information contained in thesystem model. The system model structure is then flattened to createconfiguration settings for each component in the system. Theseconfiguration settings are then saved in a simplified schema that isconsistent with the full system model.

The process continues by monitoring the configuration of the componentsand applications in the system for compliance with the configurationpolicy (act 1310). An administrator or other user typically defines thefrequency with which the components and applications are checked forcompliance. This compliance checking may occur at any interval, such asevery 10 minutes, every hour, every day, or every week. In particularembodiments, different components or applications are checked forcompliance at different intervals. For example, critical components orapplications are checked once every 10 minutes while less criticalcomponents or applications are checked once every two hours.

If any component or application is not in compliance with theconfiguration policy, the process generates an alert or a reportidentifying the non-compliance (act 1312). The alert or report may be,for example, an email message, a pager message, a cell phone message, anaudible alarm, or a pop-up message on a computer monitor. Additionally,information regarding the alert or report may be recorded in a daily logwith other alerts and activities.

Based on information contained in alerts or reports, various types ofcorrective actions can be taken. For example, a management systemoperating on the managed computer system can immediately correct aconfiguration setting when it detects the configuration setting is outof compliance with an associated configuration policy. In anotherexample, a central management system can respond to an alert by startinga process to bring the system into compliance. Additionally, a centralmanagement system can add the system that is found to be out ofcompliance to a list of systems that is later used as a target forvarious management systems. In any of these examples, the correctiveaction can use techniques such as changing a configuration setting,installing a software system, removing a software system, or running aprogram that performs an operation such as moving information off astorage device.

A management system can also enforce a configuration policy bypreventing changes from being made that would result in a configurationthat is out of compliance. The intended setting is compared with theconfiguration policy, and if it would result in a compliance violation,the change is rejected and an error message is returned. To reliablyenforce a change, the management system intercepts the change before itis applied to the system. Additionally, the management system canoperate in an advisory mode, where an application can choose to consultthe management system. For example, the application may ask if theintended change would be in compliance with the configuration policies.If the intended change would not be in compliance with the configurationpolicies, the application can choose not to make the change.

FIG. 14 is a flowchart illustrating an example process 1400 for creatinga configuration policy associated with the system. Initially, process1400 identifies application configuration settings (act 1402). Forexample, a particular application may have a dependency on anothersystem and may require a specific configuration setting to properlyinteract with the other system. The process continues by identifyingconfiguration settings associated with all component classes (act 1404).Component classes may include classes of machines, groups of machines,and the like. A particular component class may contain any number ofcomponent instances.

Next, process 1400 identifies a response action associated with eachconfiguration setting (act 1406). The response action identifies anaction to take in response to identifying a violation of a configurationconstraint. Example response actions include generating a report,activating an alarm, sending an alert message to an administrator,logging a violation in a daily log, halting operation of a component orapplication, resetting a component, or restarting an application. Aconfiguration constraint defines the allowable value(s) or a range ofvalues that are permitted for a particular configuration setting. Theprocess continues by identifying all component and application instancesin the system (act 1408). In one embodiment, component and applicationinstances are identified from the system model.

Process 1400 then identifies targeting information associated with oneor more configuration settings (act 1410). Targeting informationidentifies particular components or particular applications, or mayidentify groups of components and/or groups of applications. Forexample, a group of components may include all components of aparticular type, all components in a particular geographic region, orall components in a particular department of an organization. Theprocess continues by identifying scheduling information associated withone or more configuration settings (act 1412). Scheduling informationdetermines the frequency with which certain configuration settings arechecked for compliance with their associated constraints. As discussedabove, some configuration settings may be checked for compliance morefrequently than others.

Finally, process 1400 generates and stores a configuration policyassociated with the system (act 1414). This configuration policyincludes constraints associated with all components and applications inthe system as well as information regarding response actions, targetinginformation, and scheduling information associated with the system. Incertain implementations, an administrator or other user can modify theconfiguration policy to meet their desires or operating requirements.The configuration policy can specify, for each constraint, what thecorrective action should be (if any), or specify that only a report oralert should be created.

In one embodiment, the identification of components and applications is11 performed automatically based on information contained in the systemmodel. However, the identification of target information and theidentification of scheduling information is determined by anadministrator or other user.

System Monitoring

Systems and methods described herein are capable of detecting the healthof a managed system (e.g., good, fair, or poor) and can detect problemsand potential problems. By monitoring all components in the managedsystem, the overall health and performance of the managed system can bedetermined. Systems and methods described herein automate much of theperformance and health monitoring tasks using the model discussed below.

In a particular implementation, the SDM is created, for example, by adeveloper having knowledge of the various components, relationships, andother aspects of the system being defined. In this implementation, thedeveloper has intimate knowledge of the various components in the systemand how they interact with one another. This knowledge is useful indefining the manner in which the various components are monitored orotherwise managed.

FIG. 15 is a flowchart illustrating an example process 1500 formonitoring a system. Process 1500 can be implemented in software,firmware, and/or hardware. Initially, a service is identified, includingthe parts of the service and the interrelationship between the parts(act 1502). The process the identifies health aspects associated witheach part of the service (act 1504) and defines a health model for eachaspect (act 1506). Each health model includes multiple states andtransitions between those states. Each state may represent, for example,a health condition or a performance status that is associated with theparticular component being monitored.

The process continues by defining rules that detect transitions betweenstates and by defining knowledge for the states (act 1508). The variousdefinitions are combined into a package (also referred to as a“Management Package”) and one or more policies are defined that modifythe behavior of the package (act 1510). Systems and methods describedherein combine the various models and policies associated with a systeminto a management package that is portable. This portable managementpackage can be sold or deployed.

The monitoring policy defines the manner in which the managed system ismonitored. In a particular embodiment, the monitoring policy containsinformation regarding all instances or components to be monitored. Forexample, the monitoring policy may define the states, severities, andtransitions for one or more components. The monitoring policy may alsodefine information regarding different aspects of a particularcomponent. For example, the monitoring policy can monitor serverperformance, average response time for web page requests, databaseperformance, percentage of requests that timeout, or the number ofcomponent failures. When monitoring the performance of a component orsystem, one or more health-related alerts or messages may be generated.For example, when monitoring the average response time for web pagerequests, if the average response time increases significantly, an alertor other message may be generated indicating a problem or potentialproblem with the handling of web page requests.

The monitoring policy is also capable of monitoring service-levelcompliance (e.g., system compliance with one or more service agreements)of the system. Service level agreements may define, for example, amaximum number of page requests that fail during a particular timeperiod, or a minimum number of minutes that a particular resource orcomponent is active each month. As discussed herein, the monitoringpolicy may also identify problems, potential problems, or othersituations that may cause the system to operate improperly.

Authors and administrators typically like policies to have modifiedbehavior when encountering different environments. These differentbehaviors are described in one or more policies which are associatedwith dynamically discovered instances of the policy type.

The process then deploys the package to a management system whichdiscovers instances of components and services in a system (act 1512).The management system provides the apparatus or platform to run themodels and monitoring policies discussed herein. The monitoring policiesinclude rules to discover real instances of components, systems, andrelationships between components and/or systems. The management systemdiscovers these things and builds a model representing the system orenvironment being managed.

The management system then deploys the rules to monitor the componentsand services in the system (act 1514). The management system modifiesthe rules, as necessary, based on the administrative policies that applyto the discovered instances. Conflicts may occur between multipleadministrative policies. When a conflict occurs, the management systemresolves the conflict to generate a resulting administrative policy thatappropriately modifies the monitoring rules.

Next, the management system creates a model of the system and tracks thehealth of the components in the system (act 1516). This monitoring ofthe system is ongoing and monitors the system components for failures,poor performance, erroneous performance, and the like. The managementsystem then rolls up the health of the components to one or moreaggregation services (act 1518). A managed entity that groups orcontains other entities can express its health in terms of the health ofthe child entities—this is commonly referred to as “roll-up”. Roll-up isused to draw attention to a problem in a contained entity, in ascaleable fashion or to report on aggregate metrics.

Finally, the management system detects a root cause of a problem orerror when one or more components are detected as bad (act 1520).

The above approach simplifies the management of the components (andaspects of the components) in a system by providing smaller, manageableunits. For example, instead of pre-determining all possible transitionsbetween states in a system, each aspect (such as virtual CPUperformance) is defined along with its possible states. Each aspect isorthogonal to other aspects such that the state of each aspect haslittle or nothing to do with the state of other aspects. Monitoring ofan additional aspect is accomplished by defining the new aspect and itspossible states.

As discussed above, one or more monitoring pages contained in the SDMinclude information related to monitoring the performance and/or healthof the associated component. This information can include rulesdescribing how the associated component is to be monitored (e.g., whatevents or other criteria to look for when monitoring the component), aswell as what actions to take when a particular rule is satisfied (e.g.,record certain settings or what events occurred, generate an alert,etc.).

Additionally, one or more service level agreement pages includeinformation describing service level agreements between two or moreparties regarding the associated component (e.g., between the purchaserof the associated component and the seller from which the associatedcomponent was purchased). These pages can be accessed during operationof the system to determine, for example, whether the agreement reachedbetween the two or more parties is being met by the parties. In oneembodiment, accessing of monitoring pages and service level agreementpages is defined by the monitoring policy.

Each aspect of each component in a system has an associated monitor,which tracks the health and/or performance of the associated component.The severity of the state of each aspect is “rolled-up” to compute theseverity of the component. If a component is composed of one or morecomponents, the state gets rolled-up based on a choice of aggregationalgorithms. For example, a domain controller that cannot accept one ormore requests is put into a critical state, while delays in servicingthose requests are marked as being in a warning state. In oneembodiment, monitors have a hierarchical structure similar to thestructure shown in FIG. 1, which allows the monitors to “roll up” healthand performance information to other monitors. In particular, thehierarchy “rolls up” based on the SDM model. The hierarchy and “roll up”described herein represents one type of structure that can be used withthe described model-based system monitoring. Alternate embodiments canpropagate information through relationships in the model based onpropagation algorithms associated with each kind of relationship. Forexample, “roll up” can be performed in a containment hierarchy based ona worst-case-among-the-children algorithm.

The health of a particular component can be determined based on variousfactors, such as the availability of the component, available capacity,configuration, security policy compliance, etc. A health model is aframework for describing a managed components' potential operational,degradation and failure states.

In particular embodiments, a management system may use information frommultiple sources. For example, a management system may receive an SDMfrom one source, another SDM from a second source, and a set ofmonitoring policies from a third source. A management system can receiveinformation from any number of different sources. The management systemidentifies and handles the various relationships between objects indifferent models and/or received from different sources. Thus, themanagement system pulls together the information from various sourcesand uses all of the information in managing a particular system orenvironment.

Additionally, the same management system and the same information can beused by different administrators in different disciplines to displayalerts or data of interest to that administrator or discipline. Forexample, the management system may display application securitycompliance to an administrator responsible for overseeing such securitycompliance. The same management system (using the same information) maydisplay information regarding available storage resources to anadministrator responsible for handling or monitoring those storageresources. Thus, the management system uses filters or otherwise managesdata to display the appropriate data (e.g., requested data) to variousadministrators or disciplines.

FIG. 16 illustrates an example health model 1600. In this example,health model 1600 defines the updating of a security credentialsmonitor. During normal operation, health model 1600 is in a valid state1602. At periodic intervals, the security credentials need to berefreshed. Such a request causes the model to transition to a refreshstate 1604. If the security credentials are properly refreshed, themodel transitions back to valid state 1602. If the security credentialsare not properly refreshed, the model transitions to state 1606, whereanother attempt is made to refresh the security credentials. If thesecond attempt is successful, the model transitions back to valid state1602. Otherwise, the security refresh has failed and the modeltransitions to state 1608, which generates an alert. Thus, the health ofmodel 1600 can be determined by evaluating the current state of themodel. This information is useful in detecting, verifying, diagnosingand resolving problems with the system as well as particular componentsin the system.

Typical health models include one or more states that help detect,verify, diagnose, and resolve a problem state. For example, a problem(or potential problem) can be detected by interpretation of data thatindicates a transition to a particular state in the health model.Diagnostic information includes actions necessary to understand thenature of the detected problem. The actions include, for example,automated tasks or examining supporting data (e.g., event data andperformance data). Resolution information includes the operationsnecessary to resolve the problem.

In a particular embodiment, a monitor is configured via rules todeclaratively express conditions when state transitions should occur.The rules include various modules, which are precompiled functions thatcan deliver reusable functionality for event sourcing, probing,interpreting the collected data by checking for conditions or performinga correlation and taking action. A rule configuration defines theinteraction among the various modules. These same modules can also usedto create one or more tasks. Tasks are actions such as diagnosticfunctions or problem recovery actions.

For example, a rule may monitor various data sources or components thatgenerate events, alerts, and other notices. If a particular event oralert is detected, the rule modifies the state of the health model basedon the transition associated with the event or alert. The rule thenidentifies an appropriate response, such as taking a corrective action,generating an alert, sending an email message to an administrator, orpaging an administrator.

Certain human-readable information may be associated with a healthmodel. This information is provided as knowledge along with the monitor.The information can be supplied by the product vendor or by the user ofthe product. The information may include embedded links to views andtasks necessary to diagnose and fix a problem. Example informationprovides a summary of the problem, one or more steps to diagnose theproblem, and one or more steps to resolve the problem based on theresults of performing the diagnosis steps.

Various relationships can be defined between different managed entities(or components). Example relationships include:

-   -   a containment relationship (a particular application contains a        database),    -   a hosting relationship (a web site is hosted on IIS),    -   a communication relationship (an application is an SQL client of        a database server),    -   a reference relationship (a loose relationship between        applications, components, etc.),    -   grouping information (such as static and dynamic computer        groups. Groups can be nested or overlapping), and    -   “caused by” information (any of the above relationships can be        used to define a dependency. For example, “an underperforming        host can cause a guest to under perform.”)

A component that groups or contains other components can express itshealth or performance in terms of the health or performance of the childcomponents—this is commonly referred to as “roll-up”. Roll-up is usefulin identifying a problem in a contained component in a scaleable manner.Roll-up is also useful in reporting on aggregate metrics. Roll-up isperformed using aggregation algorithms for expressing the state,performance, and events of a container in terms of contained or groupedobjects. For example, referring back to FIG. 1, component 110 canexpress its health or performance in terms of the health or performanceof component 112 and component 114. In one embodiment, a user can definethe roll-up policy based on the SDM topology.

In addition to monitoring the health or performance of particularcomponents, administrators are interested in identifying causes offailures or other improper operation. For example, a component may failor operate improperly based on a problem with that particular component.Alternatively, a component may fail or operate improperly due to aproblem with another component. For example, if a SQL server fails,applications attempting to access the failed SQL server will likelygenerate error notices.

Analyzing a failure of one component to see if another component isactually responsible for the failure is referred to as “probable cause”analysis or “root cause” analysis. For example, a failed web service(first component) may trace its probable cause to a database (secondcomponent), which traces its probable cause to a failed SQL server(third component) that hosts the database, which traces its probablecause to a backup of disk input/output operations (fourth component) inthe underlying server.

In certain situations, it is desirable to suppress certain alerts andother notices. For example, if a SQL server fails, applicationsattempting to access the failed SQL server will generate alerts. Sincethe SQL server failure is already known, generation of additional alertsby the applications is unnecessary. These additional alerts would likelybe a distraction to the administrator attempting to correct the SQLserver failure.

In other situations, administrators may want to know the impact of achange or failure on other components. For example, referring again toFIG. 1, an administrator may want to know the impact on the health orperformance of component 112 if a change is made to the state ofcomponent 110. This “impact analysis” allows an administrator to predictthe impact on the system caused by a particular change beforeimplementing the change. For example, impact analysis can predictchanges in system performance, changes in system health, whether or notsystem level agreements will continue to be satisfied, and the like.Impact analysis uses information available through the SDM to determinethe impact of one or more changes to one or more components in thesystem. Additionally, impact analysis can determine the impact on theoverall performance and/or health of the system caused by one or morechanges. This impact analysis can be performed using the SDM informationwithout actually implementing the changes. Thus, an administrator canperform various “what if” analyses without affecting the normaloperation of the system. Rules, discussed herein, use relationships todynamically and declaratively express logic for roll-up, aggregation,root cause analysis, and impact analysis.

As mentioned above, one or more service level agreement pages of the SDMinclude information describing service level agreements between two ormore parties regarding the associated component. Service levelagreements are generally set based on the service as experienced by theusers. “Users” may include human users, software systems, hardwaresystems, and the like. Administrators can define their level of serviceas a component of the SDM. This component aggregates pre-discovered andpredefined components and rolls-up their health and performanceaccording to one or more service level agreements. To enableself-managing service structures, the grouping of components can bedynamic. For example, if a service level agreement calls for 99%availability for all print servers in Redmond, Wash., the service willadd and remove print servers automatically as they are deployed andretired. Remote monitoring services may be used to observe real orrepresentative clients.

When monitoring a system, the monitoring policy performs end-to-endanalysis of the system. End-to-end analysis of the system includesmonitoring the performance of the entire system and monitoring theperformance of a group of components that handle data, requests, orother information in a sequential manner.

For example, FIG. 17 illustrates multiple components that process datain a sequential manner. The data being processed can be any type of datareceived from any data source. Initially, a component 1702 receives thedata to be processed, followed by components 1704 and 1706. Aftercomponent 1706 has processed the data, any number of other intermediatecomponents (not shown) may process the data, after which the data isprovided to a component 1708. Each component 1702-1708 shown in FIG. 17has an associated percentage (e.g., component 1702 has an associatedpercentage of 99.0 and component 1704 has an associated percentage of98.5). These percentages indicate, for example, the current efficiencyassociated with the component or the current delay imposed by thecomponent in processing data. When viewing each component individually,the associated percentage is within a reasonable range. For example, thelowest percentage in FIG. 17 is 98.5%. If a service level agreementcalls for a minimum component performance of at least 98%, allcomponents shown in FIG. 17 satisfy the service level agreement.

However, when performing an end-to-end analysis of the components, theend-to-end performance may be unacceptable. For example, if thepercentages represent delays in processing data, the multiple delays arecumulative. If data is processed sequentially by fifteen differentcomponents, each of which introduces an average of 1.2% delay, thecumulative end-to-end delay in processing the data is 18%. Thus,although each component is individually within an acceptable operatingrange, the end-to-end analysis indicates significantly lowerperformance.

The systems and methods described herein can use the SDM to performend-to-end analysis. This end-to-end analysis can identify potentialpoints of failure or identify areas that are reducing the overall systemperformance. Although a failure may not yet have occurred, the resultsof the end-to-end analysis are helpful in avoiding failures andmaintaining the system at a high level of performance.

Capacity Planning

Systems and methods described herein are capable of estimating theperformance and capability of a managed system. These estimations areuseful in determining current and future system requirements to meet therequirements of certain types and quantities of transactions handled bythe system. This capacity planning simplifies the selection ofcomponents (and component capacities) for the system and allows thevarious components to be tested in an expected operating environmentprior to actually implementing the system. Systems and methods describedherein also permit various capacity planning activities using differentsystem architectures defined by one or more system models.

Capacity planning allows users to manage future software and hardwarerequirements proactively instead of reactively. Capacity planning ispart of a performance modeling process that guides a user'sdecision-making process before application deployment, and continues toassist them after deployment in predicting the application's behaviorunder changing loads, identifying future bottlenecks, and experimentingwith other “what if” scenarios. Example “what if” scenarios includeanticipated company growth, increased network traffic, increaseddatabase access requests, and new applications or features provided bythe system. Accurate and simple capacity planning is useful in serverconsolidation and virtualization scenarios. Proper capacity planning canavoid the over-provisioning of resources to ensure correct operation.Instead, proper capacity planning can identify the appropriate resourcesto correctly perform the desired operations.

Capacity planning uses the data contained in the SDM discussed herein.One or more SDMs may define multiple architectures that are accessed bythe capacity planning system and methods. Each architecture definitionincludes information regarding various options and constraintsassociated with the architecture. The SDM may also contain informationcollected from one or more live systems, such as performance data andconfiguration information for the various components in the system.

The SDM contains static information (e.g., the topology of softwareservices within an application) and dynamic information (e.g., thecontrol flow of a particular transaction). This information is used todescribe components, system architecture, and transaction flows (e.g., aseries of steps that perform a function).

FIG. 18 is a flowchart illustrating an example process 1800 for capacityplanning. Process 1800 can be implemented in software, firmware, and/orhardware. A “planned system” may be an existing system, proposedmodifications to an existing system, or a new system not yetimplemented.

Initially, process 1800 retrieves a model associated with a systemhaving multiple components (act 1802). In one embodiment, this model isan SDM model of the type discussed above with respect to FIGS. 1 and 2.A planned system can be defined as a hypothetical system that might beimplemented depending on the results of the capacity planning process.Alternatively, a planned system may include at least a portion of anexisting system (e.g., an expansion or modification of an existingsystem). In this situation, certain data (such as performance data)associated with the existing system may be used in modeling the plannedsystem.

The procedure continues by identifying a quantity of each type ofcomponent in a planned system (act 1804). In a particular embodiment,the SDM is scale invariant. For example, the SDM may contain informationabout different types of components, but does not necessarily indicatethe number (or quantity) of each type of component in a specific system.To properly identify the characteristics and requirements of a specificsystem, it is important to know the number of components involved in thesystem and their expected (or actual) interactions with one another.Procedure 1800 identifies transaction steps and transaction flows in theplanned system (act 1806). These transaction steps and transaction flowsare useful in determining resources (e.g., storage capacities,communication bandwidth, etc.) in the planned system.

Procedure 1800 continues by determining a cost associated with eachtransaction step in each of the transaction flows (act 1808). A “cost”can vary depending on the transaction and/or the step being discussed.For example, a cost can be time, bandwidth, storage capacity, processingcapacity, and the like. This cost information can be stored in the SDMusing one or more information pages associated with one or morecomponents. Alternatively, the cost information can be stored separatelyfrom the SDM. A particular transaction may include multiple differentsteps. In this situation, a cost is associated with each of the multiplesteps and a cost is associated with the various transitions between themultiple steps.

Next, the procedure executes a capacity planning algorithm (act 1810).The capacity planning algorithm simulates the actions taken by anapplication as it runs on a distributed system. The simulatedapplication, users, hardware, and workload can be modified to see thelikely effects of the modification on the throughput, latency, etc. ofthe application, and the utilization of the hardware. This simulationeliminates the need to build and test a real system in a test lab orsimilar setting. Various types of capacity planning approaches includesimulation, statistical analysis (e.g., trending), operational researchanalytics, queuing theory, or a hybrid approach (e.g., a combination ofany two or more approaches).

If the capacity planning algorithm returns satisfactory results (act1812), the results of the capacity planning algorithm are stored (act1814) along with information about the planned system. If the capacityplanning algorithm does not return satisfactory results, one or moreaspects of the planned system are changed (act 1816). Satisfactoryresults include, for example, worst-case time to process a transaction,maximum wait time for a response, average wait time for a response,maximum number of concurrent requests, and the like. Changes to aplanned system may include increasing storage capacity, increasingprocessing resources, increasing communication bandwidth between certaincomponents, adding components, removing components, etc.

When performing the capacity planning process, different systemarchitectures may be considered. Other variables may include differentnumbers of servers or other components, different component sizes andcomponent configurations, different storage capacities, and differenttypes and quantities of transactions. These different architecturesand/or variables allow a wide range of differences among various plannedsystems to see which system is best suited for the anticipatedtransactions.

In a particular embodiment, a planned system is defined by an SDM aswell as additional information regarding the various transactions to beexecuted, including the cost of each step in each transaction. In otherembodiments, all information about the planned system is contained in anSDM.

FIG. 19 illustrates example transactions that are performed by a plannedsystem. In this example, two separate transactions are launched inresponse to a particular request. For example, a customer may place anorder for a particular product. In other implementations, eachtransaction may be executed independently of the other transaction. Afirst transaction (Transaction 1) performs an inventory check todetermine whether the requested product is available and, if notavailable, determine a reasonable time required to obtain and deliverthe product to the customer. A second transaction (Transaction 2)performs a credit check to be sure the customer is authorized topurchase the requested product.

For example, Step 1 and Step 2 of Transaction 1 represent stepsnecessary to perform an inventory check, such as looking up a productidentification code, querying one or more warehouse databases to see ifthe product is in stock, etc. Step 3 and Step 4 of Transaction 2represent steps necessary to perform a credit check, such as verifyingpast account payments, verifying credit card information, and the like.

When evaluating a planned system, an estimation is performed todetermine an approximate number of transactions performed in a giventime period. For example, if an average of ten separate inventoryqueries are performed for each order that is placed, and the system isexpecting 5000 orders per day, then there are 50,000 expected inventoryqueries per day. Additionally, the planned system may be expected tomaintain 25,000 different product identifiers in a product database.These parameters, along with various system model information from theSDM and other information regarding the planned system are used by acapacity planning algorithm to estimate the performance of the plannedsystem. If the performance of the system is not satisfactory, changesare made to the planned system and the capacity planning algorithm isrun again to identify the results of the changes.

In one example, a first planned system has a bottleneck created by ahard disk drive. The speed and the capacity of the hard disk drive isupgraded to create a second planned system. This second planned systemencounters a bottleneck caused by lack of processor resources to handleall of the necessary operations. Thus, an additional processor or afaster processor is added to the second planned system to create a thirdplanned system. This process continues until all a planned system isdefined that is estimated to produce satisfactory results based on thecapacity planning algorithm.

Referring to the example of FIG. 19, each step (Step 1, Step 2, Step 3,Step 4) has an associated cost, which is measured in time required toperform the step as well as storage capacity and processor capacityrequired to perform the step. Transitions between steps may also haveassociated costs, such as time required to transition from one step tothe next and bandwidth required to communicate data from one step to thenext or to communicate data between different components in the plannedsystem. These costs may be estimated based on an administrator'sknowledge of similar systems or past experience with similar systems.Alternatively, one or more of these costs can be determined based onactual results from an existing system. For example, if the plannedsystem is a modification of an existing system, performance data fromthe existing system may be used to estimate similar performance data inthe modified system.

Attribute Propagation

A constraint can “flow” over a relationship between two systems orcomponents, such as a constraint on an application that makes astatement on how the operating system on which the application is hostedshould be configured. Additionally, attributes can propagate over one ormore relationships to provide a more meaningful policy, as discussed ingreater detail below. Although particular constraints, policies, andattributes are discussed herein, alternate embodiments may includeadditional constraints, policies, or attributes, or may omit certainconstraints, policies, or attributes discussed herein. Although aparticular model is described herein, alternate embodiments may use anytype of model having any type of structure for defining components in asystem.

The SDM contains static information (e.g., the topology of softwareservices within an application) and dynamic information (e.g., thecontrol flow of a particular transaction). This information is used todescribe components, system architecture, and transaction flows (e.g., aseries of steps that perform a function).

FIG. 20 is a flowchart illustrating an example process 2000 forpropagating attributes throughout a system model. Process 2000 can beimplemented in software, firmware, and/or hardware. Initially, process2000 retrieves a model associated with a system having multiplecomponents (act 2002). In one embodiment, this model is an SDM model ofthe type discussed above with respect to FIGS. 1 and 2. A particularmodel may contain any number of objects to define the associated system.

Process 2000 continues by defining (or identifying) various attributes,policies, constraints, dependencies, and other information associatedwith the system and/or particular components of the system. Thisinformation can be defined by a system administrator, a system manager,or other person responsible for managing the system. Alternatively, thisinformation may be retrieved (or received) from one or more datasources. In particular, process 2000 defines policies associated withthe system and specific components of the system (act 2004). Thesepolicies may include, for example, business policies such as data backupfrequency, licensing information, and whether the system is permitted toexport certain data.

The process further defines constraints associated with the componentsof the system (act 2006) and defines relationships between the variouscomponents of the system (act 2008). Constraints can be defined, forexample, in one or more constraint pages (discussed above), which areexamples of information pages contained in SDM 100. Certain constraintsmay be specified as part of another model (such as an SDM model of a SQLServer database), yet those constraints also become part of this SDMmodel when the other model is included. A constraint can flow over arelationship. For example, if an application A has a relationship with aSQL Server S, a constraint defined for application A can reference anattribute of server S. A constraint on application A may state thatapplication A must store its data on a RAID device. Thus, even thoughthe SQL Server S does not itself have this RAID constraint, theconstraint flows from application A to SQL Server S due to therelationship between the two items.

Dependencies include, for example, dependencies between two or morecomponents in the system. A dependency definition may (or may not)include a reason why a particular component depends on anothercomponent. A particular dependency definition may simply identify thedependency such that if one component fails, the system can determinewhat other components depend on the failed component. Dependencies mayalso be referred to as “relationships.”

Next, process 2000 defines attributes and other information associatedwith the system and/or particular components of the system (act 2010).In one example, a system may have attributes such asbusiness-importance, with possible values of 4 representingcustomer-facing-mission-critical, 3 for internal-mission-critical, 2 forinternal-standard, 1 for test, and 0 for retired. The process thendefines how the various attributes are to be propagated throughout themodel based on one or more propagation rules (act 2012). For example, ifan application has a dependency on a database, a health attribute ispropagated from the database to the application. If the database fails,the system can determine that the application fails as well.Business-importance is propagated in the opposite direction. Forexample, if the application has a business-importance rating of 3, thedatabase gets the same rating, unless it already has a higher rating.

In another implementation, an attribute propagation rule for acontainment relationship may specify how a health attribute is to bepropagated from the contained systems (the children) to the container(the parent). In many cases, the health monitoring systems give theparent the worst-case health value of the children. Thus, if any singlechild has a “red” health status, the parent gets that same healthstatus. In some situations, when the container represents a system witha redundant architecture, health monitoring systems may implement anaggressive algorithm that recognizes the redundancy. For example, theparent only gets the “red” status if at least all three children have“red” status. The attribute propagation systems and methods discussedherein allow more flexible algorithms. For example, the systems andmethods can weigh the health value of the children using thebusiness-importance rating, or traffic volume, size, or cost of eachchild system when calculating the aggregate health value for the parent.In one such model, there may be a system representing all the printersin an office. When calculating the aggregate health state of printing, alarge invoicing printer is more important and is given greater weightthan small inkjet printers on most users' desks. The systems and methodscan determine the business-importance rating, or traffic volume, size,or cost of each child by propagating attributes to other relatedsystems, including lower-level children.

Finally, after the models, policies, constraints, attributes, andpropagation rules have been defined, the process propagates theattributes throughout the model based on information contained in themodel associated with the system (act 2014). The process then interpretsthe policies during continual management of the systems (act 2016). Forexample, information contained in SDM 100, discussed above, describesrelationships and other data regarding components in the system that isuseful in propagating the attributes to the appropriate objects in thesystem model. With this knowledge of the system architecture, theattributes are propagated throughout the model.

As mentioned above, attributes can propagate over relationships. Forexample, an administrator may specify that a business-importanceattribute should propagate over the application-to-databasecommunications relationship. In this example, if application A has ahigh business-importance rating, when application A and SQL Server S areconnected with such a relationship, SQL Server S gets the samebusiness-importance rating. Using this technique for propagatingattributes, the administrator or other user can define a more meaningfulpolicy for the database storage. Namely, SQL Server S receives a policythat indicates “if my business-importance rating is 4, then I must use aRAID device to host the data.” This expresses the desired policy, butkeeps the internal details of the SQL Server out of the policiesassociated with the application.

FIG. 21 illustrates an example attribute propagation module 2102 thatreceives a system model and various attributes, and propagatesattributes throughout the model. Attribute propagation module 2102receives system model information, such as information contained in anSDM. Additionally, attribute propagation module 2102 receives policyinformation 2106, constraint information 2108, dependency information2110, and information regarding other attributes 2112. Attributepropagation module 2102 then distributes one or more attributes to anevaluation module 2114, which evaluates constraints and policies basedon the attribute values. Evaluation module 2114 detects deviations inany constraints or policies and takes appropriate action to correct thedeviation. Alternatively, evaluation module 2114 may bring the deviationto the attention of an administrator or other user.

For example, two different applications (application A and applicationB) both use a SQL Server database and the database uses a disk drive tohost the data. If application A has a business-importance rating of 1,and application B has a business-importance rating of 2, the databasegets the highest of these two ratings, which is 2. When application A isreleased to production, its business-importance rating is raised to 4,representing customer-facing-mission-critical, and this rating ispropagated to the database. If there is a policy that every databasewith business-importance of 4 must be stored on a RAID storagesubsystem, the evaluation module detects that a change to one of theapplications caused the database to be out of compliance with a policy.The evaluation module then initiates actions to correct that situationor notify an administrator of the situation. If, at a later time,Application A is removed or no longer connected to the database, thedatabase gets a lower business-importance rating and no longer requiresa costly RAID storage device. Having a RAID storage device is not aviolation of the initial policy, but it is unnecessary, and there may beanother policy that databases should not use RAID storage devices unlesstheir business-importance rating is high enough.

In another example, the propagated attribute is communicated to anadministrator when a constraint violation is detected, but not used inthe analysis. The database may have a simpler constraint that is notdependent on any propagated attribute, such as “the journaling fileshould not be installed on a compressed drive.” The corrective actionfor this constraint may be specified as “notify the administrator with awarning” because the rule is not important (not classified as a seriouserror). In this situation, the management system should not take anyform of automated corrective action or otherwise enforce the policy.However, if the rule indicates that the business-importance attributeshould be included in the notification to the administrator, theadministrator may decide to give the violation greater attention for amission-critical database than for other databases.

In yet another example, an attribute may influence the schedule by whicha management action is taken. If many systems are found to be inviolation of a particular security policy, and correcting that violationrequires manual intervention, the systems with high business-importancemay be prioritized ahead of other systems.

In a particular implementation, attribute propagation module 2102 maynot receive one or more of: policy information 2106, constraintinformation 2108, dependency information 2110, or information regardingother attributes 2112. Attribute propagation module 2102 may receivepolicy information 2106, constraint information 2108, dependencyinformation 2110, and information regarding other attributes 2112 fromany number of sources. In other embodiments, attribute propagationmodule 2102 receives additional information not shown in FIG. 21.

Example Computer Environment

FIG. 22 illustrates an example general computer environment 2200, whichcan be used to implement the techniques described herein. The computerenvironment 2200 is only one example of a computing environment and isnot intended to suggest any limitation as to the scope of use orfunctionality of the computer and network architectures. Neither shouldthe computer environment 2200 be interpreted as having any dependency orrequirement relating to any one or combination of components illustratedin the example computer environment 2200.

Computer environment 2200 includes a general-purpose computing device inthe form of a computer 2202. Computer 2202 can be, for example, acomputing device on which an application is installed or monitored, or acomputing device on which at least portions of process 300 of FIG. 3 areimplemented. Computer 2202 can be, for example, a desktop computer, ahandheld computer, a notebook or laptop computer, a server computer, agame console, and so on. The components of computer 2202 can include,but are not limited to, one or more processors or processing units 2204,a system memory 2206, and a system bus 2208 that couples various systemcomponents including the processor 2204 to the system memory 2206.

The system bus 2208 represents one or more of any of several types ofbus structures, including a memory bus or memory controller, aperipheral bus, an accelerated graphics port, and a processor or localbus using any of a variety of bus architectures. By way of example, sucharchitectures can include an Industry Standard Architecture (ISA) bus, aMicro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, aVideo Electronics Standards Association (VESA) local bus, and aPeripheral Component Interconnects (PCI) bus also known as a Mezzaninebus.

Computer 2202 typically includes a variety of computer readable media.Such media can be any available media that is accessible by computer2202 and includes both volatile and non-volatile media, removable andnon-removable media.

The system memory 2206 includes computer readable media in the form ofvolatile memory, such as random access memory (RAM) 2210, and/ornon-volatile memory, such as read only memory (ROM) 2212. A basicinput/output system (BIOS) 2214, containing the basic routines that helpto transfer information between elements within computer 2202, such asduring start-up, is stored in ROM 2212. RAM 2210 typically contains dataand/or program modules that are immediately accessible to and/orpresently operated on by the processing unit 2204.

Computer 2202 may also include other removable/non-removable,volatile/non-volatile computer storage media. By way of example, FIG. 22illustrates a hard disk drive 2216 for reading from and writing to anon-removable, non-volatile magnetic media (not shown), a magnetic diskdrive 2218 for reading from and writing to a removable, non-volatilemagnetic disk 2220 (e.g., a “floppy disk”), and an optical disk drive2222 for reading from and/or writing to a removable, non-volatileoptical disk 2224 such as a CD-ROM, DVD-ROM, or other optical media. Thehard disk drive 2216, magnetic disk drive 2218, and optical disk drive2222 are each connected to the system bus 2208 by one or more data mediainterfaces 2226. Alternatively, the hard disk drive 2216, magnetic diskdrive 2218, and optical disk drive 2222 can be connected to the systembus 2208 by one or more interfaces (not shown).

The disk drives and their associated computer-readable media providenon-volatile storage of computer readable instructions, data structures,program modules, and other data for computer 2202. Although the exampleillustrates a hard disk 2216, a removable magnetic disk 2220, and aremovable optical disk 2224, it is to be appreciated that other types ofcomputer readable media which can store data that is accessible by acomputer, such as magnetic cassettes or other magnetic storage devices,flash memory cards, CD-ROM, digital versatile disks (DVD) or otheroptical storage, random access memories (RAM), read only memories (ROM),electrically erasable programmable read-only memory (EEPROM), and thelike, can also be utilized to implement the exemplary computing systemand environment.

Any number of program modules can be stored on the hard disk 2216,magnetic disk 2220, optical disk 2224, ROM 2212, and/or RAM 2210,including by way of example, an operating system 2226, one or moreapplication programs 2228, other program modules 2230, and program data2232. Each of such operating system 2226, one or more applicationprograms 2228, other program modules 2230, and program data 2232 (orsome combination thereof) may implement all or part of the residentcomponents that support the distributed file system.

A user can enter commands and information into computer 2202 via inputdevices such as a keyboard 2234 and a pointing device 2236 (e.g., a“mouse”). Other input devices 2238 (not shown specifically) may includea microphone, joystick, game pad, satellite dish, serial port, scanner,and/or the like. These and other input devices are connected to theprocessing unit 2204 via input/output interfaces 2240 that are coupledto the system bus 2208, but may be connected by other interface and busstructures, such as a parallel port, game port, or a universal serialbus (USB).

A monitor 2242 or other type of display device can also be connected tothe system bus 2208 via an interface, such as a video adapter 2244. Inaddition to the monitor 2242, other output peripheral devices caninclude components such as speakers (not shown) and a printer 2246 whichcan be connected to computer 2202 via the input/output interfaces 2240.

Computer 2202 can operate in a networked environment using logicalconnections to one or more remote computers, such as a remote computingdevice 2248. By way of example, the remote computing device 2248 can bea personal computer, portable computer, a server, a router, a networkcomputer, a peer device or other common network node, and the like. Theremote computing device 2248 is illustrated as a portable computer thatcan include many or all of the elements and features described hereinrelative to computer 2202.

Logical connections between computer 2202 and the remote computer 2248are depicted as a local area network (LAN) 2250 and a general wide areanetwork (WAN) 2252. Such networking environments are commonplace inoffices, enterprise-wide computer networks, intranets, and the Internet.

When implemented in a LAN networking environment, the computer 2202 isconnected to a local network 2250 via a network interface or adapter2254. When implemented in a WAN networking environment, the computer2202 typically includes a modem 2256 or other means for establishingcommunications over the wide network 2252. The modem 2256, which can beinternal or external to computer 2202, can be connected to the systembus 2208 via the input/output interfaces 2240 or other appropriatemechanisms. It is to be appreciated that the illustrated networkconnections are exemplary and that other means of establishingcommunication link(s) between the computers 2202 and 2248 can beemployed.

In a networked environment, such as that illustrated with computingenvironment 2200, program modules depicted relative to the computer2202, or portions thereof, may be stored in a remote memory storagedevice. By way of example, remote application programs 2258 reside on amemory device of remote computer 2248. For purposes of illustration,application programs and other executable program components such as theoperating system are illustrated herein as discrete blocks, although itis recognized that such programs and components reside at various timesin different storage components of the computing device 2202, and areexecuted by the data processor(s) of the computer.

Various modules and techniques may be described herein in the generalcontext of computer-executable instructions, such as program modules,executed by one or more computers or other devices. Generally, programmodules include routines, programs, objects, components, datastructures, etc. that perform particular tasks or implement particularabstract data types. Typically, the functionality of the program modulesmay be combined or distributed as desired in various embodiments.

An implementation of these modules and techniques may be stored on ortransmitted across some form of computer readable media. Computerreadable media can be any available media that can be accessed by acomputer. By way of example, and not limitation, computer readable mediamay comprise “computer storage media” and “communications media.”

“Computer storage media” includes volatile and non-volatile, removableand non-removable media implemented in any method or technology forstorage of information such as computer readable instructions, datastructures, program modules, or other data. Computer storage mediaincludes, but is not limited to, RAM, ROM, EEPROM, flash memory or othermemory technology, CD-ROM, digital versatile disks (DVD) or otheroptical storage, magnetic cassettes, magnetic tape, magnetic diskstorage or other magnetic storage devices, or any other medium which canbe used to store the desired information and which can be accessed by acomputer.

“Communication media” typically embodies computer readable instructions,data structures, program modules, or other data in a modulated datasignal, such as carrier wave or other transport mechanism. Communicationmedia also includes any information delivery media. The term “modulateddata signal” means a signal that has one or more of its characteristicsset or changed in such a manner as to encode information in the signal.By way of example, and not limitation, communication media includeswired media such as a wired network or direct-wired connection, andwireless media such as acoustic, RF, infrared, and other wireless media.Combinations of any of the above are also included within the scope ofcomputer readable media.

Alternatively, portions of the framework may be implemented in hardwareor a combination of hardware, software, and/or firmware. For example,one or more application specific integrated circuits (ASICs) orprogrammable logic devices (PLDs) could be designed or programmed toimplement one or more portions of the framework.

CONCLUSION

Although the invention has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the invention defined in the appended claims is not necessarilylimited to the specific features or acts described. Rather, the specificfeatures and acts are disclosed as exemplary forms of implementing theclaimed invention.

1. A method comprising: accessing a set of one or more models, the oneor more models including: a model of an application, the model of theapplication including one or more information pages for each of one ormore components or relationships in the model of the application; or amodel of a system, the model of the system representing one or moremanaged systems and including characteristics and relationships of theone or more managed systems; performing, with the set of one or moremodels, at least two of: provisioning systems based on the set of one ormore models; provisioning virtual systems based on the set of one ormore models; provisioning test environments based on the set of one ormore models; updating the set of one or more models based on deploymentsmade in the system; predicting system capacity based on the set of oneor more models; monitoring health of the system based on the set of oneor more models; managing configurations of the system based on the setof one or more models; or updating the set of one or more models bypropagating attributes.
 2. A method as recited in claim 1, wherein theset of one or more models includes both the model of the application andthe model of the system.
 3. A method as recited in claim 1, wherein theperforming comprises: performing at least one of: the provisioningsystems based on the set of one or more models; the provisioning virtualsystems based on the set of one or more models; or the provisioning testenvironments based on the set of one or more models; and performing atleast one of: the updating the set of one or more models based ondeployments made in the system; the predicting system capacity based onthe set of one or more models; the monitoring health of the system basedon the set of one or more models; the managing configurations of thesystem based on the set of one or more models; or the updating the setof one or more models by propagating attributes.
 4. A method as recitedin claim 3, wherein the performing at least one of the updating, thepredicting, the monitoring, the managing, or the updating comprisesperforming each of: the updating the set of one or more models based ondeployments made in the system; the predicting system capacity based onthe set of one or more models; the monitoring health of the system basedon the set of one or more models; the managing configurations of thesystem based on the set of one or more models; and the updating the setof one or more models by propagating attributes.
 5. A method as recitedin claim 1, wherein the model of the system includes a plurality ofcomponents, and wherein the predicting system capacity comprises:identifying relationships among the plurality of components based on themodel of the system; identifying transactions to be performed by thesystem; identifying a cost associated with each of the identifiedtransactions; and simulating operation of the system using the model ofthe system and the identified costs.
 6. A method as recited in claim 1,wherein the updating the set of one or more models by propagatingattributes comprises: identifying a plurality of attributes associatedwith the system; determining a manner in which the plurality ofattributes are to be propagated throughout the system; and propagatingthe plurality of attributes to a plurality of components of the systembased on information contained in the model of the system.
 7. One ormore computer readable media having stored thereon a plurality ofinstructions that, when executed by one or more processors, causes theone or more processors to: create one or more of: an application model,the application model including one or more information pages for eachof one or more components or relationships in the application model; ora system model, the system model representing one or more managedsystems and including characteristics and relationships of the one ormore managed systems; do two or more of: provision systems based on thecreated one or more models; provision virtual systems based on thecreated one or more models; provision test environments based on thecreated one or more models; update the created one or more models basedon deployments made in the system; predict system capacity based on thecreated one or more models; monitor health of the system based on thecreated one or more models; manage configurations of the system based onthe created one or more models; or update the created one or more modelsby propagating attributes.
 8. One or more computer readable media asrecited in claim 7, wherein to create one or more of the applicationmodel and the system model is to create both the application model andthe system model.
 9. One or more computer readable media as recited inclaim 7, wherein the plurality of instructions further causes the one ormore processors to: do one or more of: provision systems based on thecreated one or more models; provision virtual systems based on thecreated one or more models; or provision test environments based on thecreated one or more models; and do one or more of: update the createdone or more models based on deployments made in the system; predictsystem capacity based on the created one or more models; monitor healthof the system based on the created one or more models; manageconfigurations of the system based on the created one or more models; orupdate the created one or more models by propagating attributes.
 10. Oneor more computer readable media as recited in claim 9, wherein to do oneor more of update the created one or more models based on deploymentsmade in the system, predict system capacity based on the created one ormore models, monitor health of the system based on the created one ormore models, manage configurations of the system based on the createdone or more models, or update the created one or more models bypropagating attributes is to do each of update the created one or moremodels based on deployments made in the system, predict system capacitybased on the created one or more models, monitor health of the systembased on the created one or more models, manage configurations of thesystem based on the created one or more models, or update the createdone or more models by propagating attributes.
 11. One or more computerreadable media as recited in claim 7, wherein the one or more managedsystems comprises a plurality of computing devices and a plurality ofsoftware applications installed on the plurality of computing devices.12. One or more computer readable media as recited in claim 7, whereinthe plurality of instructions further cause the one or more processorsto: receive notification of a problem from a first component of thesystem; determine a cause of the problem, the determination being madeat least in part based on the created one or more models; and identifyat least one component associated with the cause of the problem.
 13. Oneor more computer readable media as recited in claim 7, wherein theplurality of instructions further cause the one or more processors to:identify relationships among a plurality of components of the systembased on the created one or more models; identify a proposed change toat least one of the plurality of components; and determine an expectedimpact on the system caused by the proposed change, the determinationbeing made at least in part based on the created one or more models. 14.A system comprising: means for accessing one or more of an applicationmodel and a system model, the application model including one or moreinformation pages for each of one or more components or relationships inthe application model, and the system model representing one or moremanaged systems and including characteristics and relationships of theone or more managed systems; two or more of: means for provisioningsystems based on one or more of the application model and the systemmodel; means for provisioning virtual systems based on one or more ofthe application model and the system model; means for provisioning testenvironments based on one or more of the application model and thesystem model; means for updating one or more of the application modeland the system model based on deployments made in the system; means forpredicting system capacity based on one or more of the application modeland the system model; means for monitoring health of the system based onone or more of the application model and the system model; means formanaging configurations of the system based on one or more of theapplication model and the system model; or means for updating one ormore of the application model and the system model by propagatingattributes.
 15. A system as recited in claim 14, wherein the means foraccessing comprises means for accessing both the application model andthe system model.
 16. A system as recited in claim 14, furthercomprising: at least one of: the means for provisioning systems based onone or more of the application model and the system model; the means forprovisioning virtual systems based on one or more of the applicationmodel and the system model; the means for provisioning test environmentsbased on one or more of the application model and the system model; andat least one of: the means for updating one or more of the applicationmodel and the system model based on deployments made in the system; themeans for predicting system capacity based on one or more of theapplication model and the system model; the means for monitoring healthof the system based on one or more of the application model and thesystem model; the means for managing configurations of the system basedon one or more of the application model and the system model; or themeans for updating one or more of the application model and the systemmodel by propagating attributes.
 17. A system as recited in claim 16,further comprising all of: the means for updating one or more of theapplication model and the system model based on deployments made in thesystem; the means for predicting system capacity based on one or more ofthe application model and the system model; the means for monitoringhealth of the system based on one or more of the application model andthe system model; the means for managing configurations of the systembased on one or more of the application model and the system model; orthe means for updating one or more of the application model and thesystem model by propagating attributes.